BCM43602 + PCI passthrough causing freeze

BCM43602 + PCI passthrough causing freeze

[James Prestwood]

Hi,

I posted about a month ago on linux-wireless about an Ath9k card that
was causing my host machine to freeze/lock up when doing PCI
passthrough into a VM. This was resolved by adding:

DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0034,
quirk_no_bus_reset);

to drivers/pci/quirks.c and rebuilding the host kernel.

Original thread: 
https://marc.info/?l=linux-wireless&m=154689580213002&w=2

I am now trying to get this BCM43602 card working under the same
conditions but again I am seeing the host machine freeze when starting
the VM. I did try adding a similar line for this card, which actually
prevented the machine from freezing, but I am seeing this when starting
the VM:

qemu-system-x86_64: vfio: Cannot reset device 0000:0a:00.0, no
available reset mechanism.

And once inside the VM the device is UNCLAIMED and not usable:

$ lshw -C network

*-network:2 UNCLAIMED
       description: Network controller
       product: BCM43602 802.11ac Wireless LAN SoC
       vendor: Broadcom Limited
       physical id: 6
       bus info: pci@0000:00:06.0
       version: 01
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress cap_list
       configuration: latency=0
       resources: memory:fe890000-fe897fff memory:fe400000-fe7fffff

This change was really a shot in the dark as I only have a vague
understanding of what its actually doing. I see other entries in
quirks.c for the Broadcom vendor ID but would rather not go poking
around here without any direction.

Thanks,
James

Re: BCM43602 + PCI passthrough causing freeze

[Alex Williamson]

On Thu, 31 Jan 2019 09:36:58 -0800
James Prestwood <james.prestwood@linux.intel.com> wrote:

> Hi,
> 
> I posted about a month ago on linux-wireless about an Ath9k card that
> was causing my host machine to freeze/lock up when doing PCI
> passthrough into a VM. This was resolved by adding:
> 
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0034,
> quirk_no_bus_reset);
> 
> to drivers/pci/quirks.c and rebuilding the host kernel.
> 
> Original thread: 
> https://marc.info/?l=linux-wireless&m=154689580213002&w=2
> 
> I am now trying to get this BCM43602 card working under the same
> conditions but again I am seeing the host machine freeze when starting
> the VM. I did try adding a similar line for this card, which actually
> prevented the machine from freezing, but I am seeing this when starting
> the VM:
> 
> qemu-system-x86_64: vfio: Cannot reset device 0000:0a:00.0, no
> available reset mechanism.
> 
> And once inside the VM the device is UNCLAIMED and not usable:
> 
> $ lshw -C network
> 
> *-network:2 UNCLAIMED
>        description: Network controller
>        product: BCM43602 802.11ac Wireless LAN SoC
>        vendor: Broadcom Limited
>        physical id: 6
>        bus info: pci@0000:00:06.0
>        version: 01
>        width: 64 bits
>        clock: 33MHz
>        capabilities: pm msi pciexpress cap_list
>        configuration: latency=0
>        resources: memory:fe890000-fe897fff memory:fe400000-fe7fffff
> 
> This change was really a shot in the dark as I only have a vague
> understanding of what its actually doing. I see other entries in
> quirks.c for the Broadcom vendor ID but would rather not go poking
> around here without any direction.

Welcome to the world of "all hardware is broken".  If masking bus reset
prevents the system freeze then a) something about triggering a bus
reset on this link makes your system very unhappy, and b) there are no
other generic reset mechanisms available for this device.  The error
message you receive from QEMU is basically a warning about b), we don't
know how to reset the device, therefore you may have trouble with it
behaving reliably in the VM, which appears to be true in this case.
There are no easy options here, either we need to find something that
makes bus reset work, find some way to implement a device specific
reset for this endpoint, or maybe debug why the guest driver is unhappy
claiming the device and massage the device somewhere in the hypervisor
or the driver to accept the device.  Thanks,

Alex