Re: [libvirt-users] PCI passthrough fails in virsh: iommu group is not viable

On 08/12/2015 02:34 PM, Alex Holst wrote: > I would really appreciate some pointers on what I am doing wrong here. > > I have a need to run multiple virtual guests which have each their own GPU and > some USB controllers passed-through. I am able to run one of the guests like > this (assuming vfio stuff has happened elsewhere), but I would prefer to use > virsh:

> > kvm -M q35 -m 8192 -cpu host,kvm=off \ > -smp 4,sockets=1,cores=4,threads=1 \ > -bios /usr/share/seabios/bios.bin -vga none \ > -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ > -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \ > -device vfio-pci,host=02:00.1,bus=root.1,addr=00.1 \ > -device vfio-pci,host=00:1d.0,bus=pcie.0 \ > -device vfio-pci,host=00:1a.0,bus=pcie.0 \ > -nographic -boot menu=on /vm2/foo.img > > I found the hardware addresses using lspci. When I invoke the same machine with virsh with what > I believe are the same addresses, 1) The XML that you provide at the end shows you only assigning 02:00.0, but not 02:00.1, and you are using managed='yes', so you are depending on libvirt to unbind any host driver and bind vfio-pci to the devices. If 02:00.0 and 02:00.1 are both in iommu group 18, but one of them isn't bound to vfio-pci, qemu will give "some kind of error" when it tries to assign any other device in the group. 2) your example qemu commandline uses the q35 machinetype, but your example libvirt domain uses pc-i440fx-utopic machinetype, so the bus structure is completely different. Assuming a recent enough libvirt, you should be able to create a virtual machine based on q35 and attach the devices to pcie-root (bus 0). You wouldn't be able to add an ioh3420 controller in unless you are running libvirt built from upstream master - support for that was just pushed last weekend. (it is a new controller defined like this: <controller type='pci' model='pcie-root-port'/> 3) Doing the above *may* eliminate another problem that your current definition has - it has an emulated video device at 00:02.0, then the passthrough video device at 00:04.0. It's likely that even if you do get the domain started up, you'll end up with the passthrough vga as a secondary (which I'm guessing isn't what you want). 4) I don't know what "x-vga=on" is, but libvirt doesn't directly support that. If it is necessary, you would need to add it using libvirt's "qemu commandline passthrough": http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html (you can add a "-set", "device.hostdev0.x-vga=on" I think) 5) The libvirt definition you've provided add several other devices that you don't have in your qemu commandline which may get in the way of what you want to do; in particular the tablet, mouse, and keyboard. You'll probably want to trim those out (and if you're passing through USB, you'll likely want to replace all of the <controller type='usb'> elements with a single <controller type='usb' model='none'/> 6) your qemu commandline specifies an exact bios location, which you haven't done in the libvirt definition. If that isn't the default bios, then you'll want to look into how to specify a non-default bios file here: http://www.libvirt.org/formatdomain.html 7) If you're going to stick with the pc-ii440fx machinetype and your guest doesn't absolutely require a SATA disk, you'd probably be better off letting it attach to the 440fx's IDE controller instead (or even better, if your guest OS supports the virtio disk driver, use that since the performance will be *greatly* improved). (likewise, replace the network interface's "model type='e1000'" with "model type='virtio'" if you can).