On Thu, 31 Jan 2019 09:36:58 -0800 James Prestwood <james.prestwood@xxxxxxxxxxxxxxx> 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
