From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
To: jgg@ziepe.ca, alex@shazbot.org, bhelgaas@google.com, jjohnson@kernel.org
Cc: johannes@sipsolutions.net, mani@kernel.org, yishaih@nvidia.com,
skolothumtho@nvidia.com, kevin.tian@intel.com,
linux-pci@vger.kernel.org, kvm@vger.kernel.org,
linux-wireless@vger.kernel.org, ath11k@lists.infradead.org,
ath12k@lists.infradead.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org,
Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Subject: [PATCH v2 0/7] Enable Qualcomm WiFi PCIe passthrough to VMs
Date: Sun, 11 Oct 2026 09:45:07 +0200 [thread overview]
Message-ID: <20261011074514.515894-1-jtornosm@redhat.com> (raw)
This series enables Qualcomm ath11k/ath12k WiFi devices to work in VM
passthrough scenarios, addressing a long-standing issue where these
devices fail to initialize when passed through to VMs via VFIO.
Qualcomm ath11k/ath12k WiFi devices have been broken in VM passthrough
since they were introduced. The Qualcomm firmware has its own interrupt
controller with private registers that need to be programmed with MSI
addr/data. The driver extracts the addr/data from the MSI descriptor
and programs the firmware's private registers. In a VM, the driver
only sees virtual (IOVA) addr/data, but the firmware's private writes
bypass the IOMMU, so they need the physical host values. This causes
firmware initialization to fail with errors like "BHI offset:
0xffffffff is out of range".
Multiple attempts have been made to solve this over the past 2 years:
March 2024: Workaround using module parameters [1]
- Required manually copying MSI values from host to VM
- Rejected by Johannes Berg as too manual, suggested VMM solution
August 2024: QEMU + kernel solution by Alex Williamson [2]
- Kernel disables MSI virtualization, QEMU intercepts config writes
- Uses brute force pattern matching to infer MSI data writes
- Stuck as RFC - no progress in 8+ months
No action from Qualcomm: Despite multiple reports, no vendor solution
The solution in this series provides a clean, kernel-only approach that
addresses the previous concerns. The PCI reset support for these devices
has already landed in linux-next (commit f8522a518e59 "PCI: Add device-
specific reset for Qualcomm WCN6855/WCN7850 WLAN") [3], solving the device
reset path for VFIO passthrough. This MSI series is the remaining
piece, with both in place, these Qualcomm WiFi devices would be fully
operational in VMs for the first time.
In practice, this specific behavior (firmware requiring physical host
MSI addresses in private registers, bypassing the IOMMU) has only
been observed in Qualcomm ath11k/ath12k devices. A device-specific
approach seems appropriate, and the VFIO variant driver pattern fits
well for this, following the same established pattern as mlx5-vfio-pci
and nvgrace-gpu for their own device-specific needs.
Architecture:
1. qcom-vfio-pci variant driver caches physical host MSI values and
exposes them via extended config space with magic signature "QMSI".
Device-specific hardware quirks belong only in kernel drivers, not
userspace, independent of the tools used.
2. VM drivers (ath11k/ath12k) automatically discover and use cached values
3. PCIe link recovery handles VM timing variations
Thoroughly tested: 3 VMs across 2 WiFi generations, all devices
successfully initialized and are ready for use.
- VM1: ath11k (WCN6855)
- VM2: ath11k (WCN6855)
- VM3: ath12k (WCN7850)
Series structure:
Patch 1/7: PCI helper to find free space in extended config space
for device-specific data exchange between host and VM drivers
Patch 2/7: Shared header defining the MSI cache protocol between
the host variant driver and VM drivers
Patch 3/7: qcom-vfio-pci variant driver that caches host physical
MSI address/data and exposes them to VMs through extended config
space
Patch 4/7: ath11k PCIe link recovery retry to handle initialization
timing variations in VM environments
Patch 5/7: ath11k support to read cached host MSI values and
configure firmware with correct physical addresses, making the
device operational in VMs
Patch 6/7: ath12k PCIe link recovery retry to handle initialization
timing variations in VM environments
Patch 7/7: ath12k support to read cached host MSI values and
configure firmware with correct physical addresses, making the
device operational in VMs
[1] https://lore.kernel.org/all/20240322104912.94811-1-jtornosm@redhat.com/
[2] https://lore.kernel.org/kvm/20240812170014.1583783-1-alex.williamson@redhat.com/
[3] https://lore.kernel.org/all/20261005105436.83962-1-jtornosm@redhat.com/
[4] Original problem report:
https://lore.kernel.org/all/fc6bd06f-d52b-4dee-ab1b-4bb845cc0b95@quicinc.com/
---
v2: Complete cover letter with more information
Address Sashiko comments
v1: https://lore.kernel.org/all/20260930140833.576941-1-jtornosm@redhat.com/
Jose Ignacio Tornos Martinez (7):
PCI: Add pci_find_free_ext_cap_offset() helper
vfio: Add qcom_vfio.h header for MSI cache protocol
vfio/pci: Add qcom-vfio-pci variant driver
ath11k: Add PCIe link recovery retry for VMs
ath11k: Use VFIO MSI cache when available
ath12k: Add PCIe link recovery retry for VMs
ath12k: Use VFIO MSI cache when available
next reply other threads:[~2026-10-11 7:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-11 7:45 Jose Ignacio Tornos Martinez [this message]
2026-10-11 7:45 ` [PATCH v2 1/7] PCI: Add pci_find_free_ext_cap_offset() helper Jose Ignacio Tornos Martinez
2026-10-11 7:45 ` [PATCH v2 2/7] vfio: Add qcom_vfio.h header for MSI cache protocol Jose Ignacio Tornos Martinez
2026-10-11 7:45 ` [PATCH v2 3/7] vfio/pci: Add qcom-vfio-pci variant driver Jose Ignacio Tornos Martinez
2026-10-11 7:45 ` [PATCH v2 4/7] ath11k: add PCIe link recovery retry Jose Ignacio Tornos Martinez
2026-10-11 7:45 ` [PATCH v2 5/7] ath11k: Use VFIO MSI cache when available Jose Ignacio Tornos Martinez
2026-10-11 7:45 ` [PATCH v2 6/7] ath12k: add PCIe link recovery retry Jose Ignacio Tornos Martinez
2026-10-11 7:45 ` [PATCH v2 7/7] ath12k: Use VFIO MSI cache when available Jose Ignacio Tornos Martinez
2026-10-11 18:22 ` [PATCH v2 0/7] Enable Qualcomm WiFi PCIe passthrough to VMs Jeff Johnson
2026-10-12 14:48 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261011074514.515894-1-jtornosm@redhat.com \
--to=jtornosm@redhat.com \
--cc=alex@shazbot.org \
--cc=ath11k@lists.infradead.org \
--cc=ath12k@lists.infradead.org \
--cc=bhelgaas@google.com \
--cc=jgg@ziepe.ca \
--cc=jjohnson@kernel.org \
--cc=johannes@sipsolutions.net \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mani@kernel.org \
--cc=skolothumtho@nvidia.com \
--cc=yishaih@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®