vfio/pci: Qualcomm PCIe WiFi devices drop link during FLR causing host AER crash

vfio/pci: Qualcomm PCIe WiFi devices drop link during FLR causing host AER crash

[Nazar Mokrynskyi]

Several Qualcomm PCIe WiFi devices drop their PCIe link as part of their
internal reset sequence. Under bare metal this is transparent because the
host root complex performs link retraining automatically. Under VFIO
passthrough, the link-drop generates an uncorrectable AER error that
escalates through the parent bridge to the host, crashing it.

Affected devices confirmed so far:
  17cb:1107  WCN7850  (ath12k driver)
  17cb:1109  QCN9274  (ath12k driver)

Other Qualcomm PCIe WiFi devices from the same family should all
exhibit the same behavior and I believe ath11k devices as well since
they share a lot of the code.

The host crashes both when the VM is gracefully shut down or rebooted
(the guest driver performs a reset as part of its shutdown sequence) and
when the VM is forcefully destroyed. In both cases the crash is caused by
a PCIe link-drop from the device that the host AER handler treats as
fatal.

The only available workaround is pci=noaer on the host kernel command
line, which disables AER globally and breaks ACS-based IOMMU group
isolation required for passing other devices to other VMs.

The driver-side initialization issue - the device also drops its link
when the guest driver probes it on boot - has been worked around in
OpenWrt by skipping the global reset on initial power-up. See:
https://github.com/openwrt/openwrt/pull/22969

However, graceful shutdown and force-destroy both remain broken and
continue to crash the host, as the device performs a reset during driver
shutdown and the host crashes regardless of how the VM exits.

The fix should be in vfio-pci: when taking ownership of a device, suppress
AER error reporting on that device for the duration of guest ownership.
This prevents guest-triggered hardware behaviors, including link-drops
caused by device resets initiated by the guest driver, from crashing the
host.

Whether this should be applied generally to all vfio-pci devices or
only to specific device IDs via a quirk is left to maintainer discretion.
A general approach is defensible: suppressing error reporting on a device
handed to an untrusted guest is correct behavior regardless of whether the
device drops its link, as the host cannot meaningfully act on errors
generated by guest-controlled hardware activity.
If this is not done by default, a kernel option under `vfio-pci` like
`ids` would be nice for those who need to check whether the quirk is
needed before reporting it upstream.

This has been happening for as long as I owned ath11k (QCN9074) and
ath12k (QCN9274) devices under different kernel/QEMU versions and others
reported the same in various places:
https://forum.openwrt.org/t/qcn9274-crashes-the-system-during-driver-load/239491?u=nazar-pc
https://github.com/openwrt/openwrt/issues/17193

Hardware context: these devices are Qualcomm 802.11be (WiFi 7) PCIe
modules commonly used in router/AP hardware and passed through to
OpenWRT to create a virtualized access point.

-- 
Sincerely, Nazar Mokrynskyi
github.com/nazar-pc

Re: vfio/pci: Qualcomm PCIe WiFi devices drop link during FLR causing host AER crash

[Jason Gunthorpe]

On Sat, Apr 18, 2026 at 12:24:07AM +0300, Nazar Mokrynskyi wrote:
> Several Qualcomm PCIe WiFi devices drop their PCIe link as part of their
> internal reset sequence. Under bare metal this is transparent because the
> host root complex performs link retraining automatically. Under VFIO
> passthrough, the link-drop generates an uncorrectable AER error that
> escalates through the parent bridge to the host, crashing it.

If AER's crash the system then it is not compatible with VFIO, IMHO.

For VFIO to work as designed the platform must be able to safely
contain all the errors the PCI device can generate.

Jason

Re: vfio/pci: Qualcomm PCIe WiFi devices drop link during FLR causing host AER crash

[Alex Williamson]

On Mon, Apr 20, 2026, at 6:24 AM, Jason Gunthorpe wrote:
> On Sat, Apr 18, 2026 at 12:24:07AM +0300, Nazar Mokrynskyi wrote:
>> Several Qualcomm PCIe WiFi devices drop their PCIe link as part of their
>> internal reset sequence. Under bare metal this is transparent because the
>> host root complex performs link retraining automatically. Under VFIO
>> passthrough, the link-drop generates an uncorrectable AER error that
>> escalates through the parent bridge to the host, crashing it.
>
> If AER's crash the system then it is not compatible with VFIO, IMHO.
>
> For VFIO to work as designed the platform must be able to safely
> contain all the errors the PCI device can generate.

Aren't these also the WiFi devices that we tried to quirk because the driver writes the guest view of the MSI address/data elsewhere in the device which breaks interrupt virtualization?  The quirk was very fragile and never got merged, so I'm not sure how these devices are even useful with vfio.  Thanks,

Alex

Re: vfio/pci: Qualcomm PCIe WiFi devices drop link during FLR causing host AER crash

[Nazar Mokrynskyi]

This is happening on Gigabyte MZ32-AR0 motherboard with AMD Epyc Zen 2 CPU.

Non-vfio PCIe errors did not crash the system when I observed long time ago.
This case with VFIO is the only one that crashes my system right now, but I have no idea how to debug this to provide more info, so let me know if there is something I can do.
Maybe there are different kinds of errors and only some of them cause the machine to crash?

I just get this after system resets shown by BIOS:

> Warning: PCI-Express PERR/SERR error detected.
No such issue with these devices on the host, at least from what I observed and read online.

Running them under VM also requires the following hacks (libvirtd) that I have not found a way to get rid of (yet):

> |<features> <ioapic driver="qemu"/> </features> <devices> <iommu model="intel"> <driver intremap="on" caching_mode="on"/> </iommu> </devices>|
With all this the device does work, I'm using it right now.
But I can't turn off or reboot the VM without crashing the host at the same time, which is suboptimal.

Sincerely, Nazar Mokrynskyi
github.com/nazar-pc

20.04.26 15:44, Alex Williamson:
>
> On Mon, Apr 20, 2026, at 6:24 AM, Jason Gunthorpe wrote:
>> On Sat, Apr 18, 2026 at 12:24:07AM +0300, Nazar Mokrynskyi wrote:
>>> Several Qualcomm PCIe WiFi devices drop their PCIe link as part of their
>>> internal reset sequence. Under bare metal this is transparent because the
>>> host root complex performs link retraining automatically. Under VFIO
>>> passthrough, the link-drop generates an uncorrectable AER error that
>>> escalates through the parent bridge to the host, crashing it.
>> If AER's crash the system then it is not compatible with VFIO, IMHO.
>>
>> For VFIO to work as designed the platform must be able to safely
>> contain all the errors the PCI device can generate.
> Aren't these also the WiFi devices that we tried to quirk because the driver writes the guest view of the MSI address/data elsewhere in the device which breaks interrupt virtualization?  The quirk was very fragile and never got merged, so I'm not sure how these devices are even useful with vfio.  Thanks,
>
> Alex

Re: vfio/pci: Qualcomm PCIe WiFi devices drop link during FLR causing host AER crash

[Nazar Mokrynskyi]

Wanted to follow-up here to see what the next steps might be.
I'm okay with testing custom patches, I can even try to come up with one using LLMs if it is not too difficult.

I'm very much intersted in interrupts working properly too, which should greatly help with performance (with my current setup it isn't all that great honesly).

Sincerely, Nazar Mokrynskyi
github.com/nazar-pc

20.04.26 15:49, Nazar Mokrynskyi:
> This is happening on Gigabyte MZ32-AR0 motherboard with AMD Epyc Zen 2 CPU.
>
> Non-vfio PCIe errors did not crash the system when I observed long time ago.
> This case with VFIO is the only one that crashes my system right now, but I have no idea how to debug this to provide more info, so let me know if there is something I can do.
> Maybe there are different kinds of errors and only some of them cause the machine to crash?
>
> I just get this after system resets shown by BIOS:
>
>> Warning: PCI-Express PERR/SERR error detected.
> No such issue with these devices on the host, at least from what I observed and read online.
>
> Running them under VM also requires the following hacks (libvirtd) that I have not found a way to get rid of (yet):
>
>> |<features> <ioapic driver="qemu"/> </features> <devices> <iommu model="intel"> <driver intremap="on" caching_mode="on"/> </iommu> </devices>|
> With all this the device does work, I'm using it right now.
> But I can't turn off or reboot the VM without crashing the host at the same time, which is suboptimal.
>
> Sincerely, Nazar Mokrynskyi
> github.com/nazar-pc
>
> 20.04.26 15:44, Alex Williamson:
>> On Mon, Apr 20, 2026, at 6:24 AM, Jason Gunthorpe wrote:
>>> On Sat, Apr 18, 2026 at 12:24:07AM +0300, Nazar Mokrynskyi wrote:
>>>> Several Qualcomm PCIe WiFi devices drop their PCIe link as part of their
>>>> internal reset sequence. Under bare metal this is transparent because the
>>>> host root complex performs link retraining automatically. Under VFIO
>>>> passthrough, the link-drop generates an uncorrectable AER error that
>>>> escalates through the parent bridge to the host, crashing it.
>>> If AER's crash the system then it is not compatible with VFIO, IMHO.
>>>
>>> For VFIO to work as designed the platform must be able to safely
>>> contain all the errors the PCI device can generate.
>> Aren't these also the WiFi devices that we tried to quirk because the driver writes the guest view of the MSI address/data elsewhere in the device which breaks interrupt virtualization?  The quirk was very fragile and never got merged, so I'm not sure how these devices are even useful with vfio.  Thanks,
>>
>> Alex