https://bugzilla.kernel.org/show_bug.cgi?id=81841 --- Comment #7 from Alex Williamson <alex.williamson@xxxxxxxxxx> --- (In reply to Marti Raudsepp from comment #6) > (In reply to Alex Williamson from comment #5) > > What if you use vfio-pci instead of pci-assign? > > I run into the dreaded error: > vfio: error, group 9 is not viable, please ensure all devices within the > iommu_group are bound to their vfio bus driver > > There are some proposed workarounds on the web, like passing > vfio_iommu_type1.allow_unsafe_interrupts=1 or pci=realloc, but these seem to > change nothing for me. None of these remotely address the issue. If you're running at least 3.12 there are quirks for the following AMD southbridge components: * 1002:4385 SBx00 SMBus Controller * 1002:439c SB7x0/SB8x0/SB9x0 IDE Controller * 1002:4383 SBx00 Azalia (Intel HDA) * 1002:439d SB7x0/SB8x0/SB9x0 LPC host controller * 1002:4384 SBx00 PCI to PCI Bridge * 1002:4399 SB7x0/SB8x0/SB9x0 USB OHCI2 Controller If your bridge does not match these, then AMD will need to confirm whether isolation is provided between your devices. There is an ACS override patch floating around which allows assuming device isolation, but this is generally a bad idea, can introduce obscure bugs, and will not be merged upstream. > So I tried adding all the PCI devices in the IOMMU group as passthrough > devices (including IDE, SMBus, audio and OHCI controllers). But then QEMU's > SeaBIOS gets so confused it can no longer find a hard drive to boot off. Note that it's not required to assign all the devices, they simply need to be detached from host drivers (ie. bound to pci-stub or vfio-pci). -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
