Hi Samuel and the list, I'm reviving this old thread in the hopes that you or another user may know the answer to a question I have. The full thread is here: https://www.redhat.com/archives/vfio-users/2016-February/msg00110.html
Here's a bit of context, followed by my question: > In short, "sudo setpci -s0:14.0 0xd0.W=0x0000" will pass through all of > your ports. > > I was planning to write a blog post about it this month, but I haven't > gotten to it yet, so I guess I'll write it here. I have been using this > setup since December, and everything works without any issues. I had > done like you (playing with the firmware options) and gotten nowhere; I > finally found a Google+ post[0] (the user appears to have been deleted) > with a link to the 9 series PCH datasheet[1], which has been immensely > useful. This technique worked really well for me. I'm passing through my XHCI controller to the guest and use my EHCI controllers in the host. This is because I need the extra performance of USB 3.0 in my guest moreso than the host. The only problem with this approach is that upon bootup, usb devices will not work on my host until I run the setpci command and get some ports (i.e. my keyboard/mouse) routed over to EHCI. This isn't so bad, since I can stick setpci in my startup script and be on my way, but what I've also found is that when a qemu/kvm guest starts up, it sends some kind of pci reset to the vfio pci device that's being passed through (the XHCI controller, in this case), and that causes my port routings to get reset again. I have to run setpci yet again to get my mouse/keyboard working again on the host. Does anyone know of a sensible way to more permanently set the port routing mask so it survives these pci resets? Thanks for writing this up last year, Andrew _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
