** Description changed: + [Impact] + + * using PCI hotplug based on vfio fails if the guest was not started with + at least one hostdev already passed through. + + * After Artful we dropped an apparmor rule due to an upstream discussion + and identifying it as not needed. Unfortunately that was a mistake and + we now identified the use case. With that I brought the change upstream + and now backport it to the affected releases. + + [Test Case] + + * Get a KVM guest e.g. via uvtool-libvirt + + * Select a pci device to hotplug (see lspci) + Create a XML file based on this like for me the device on 0xdb in my + example + <hostdev mode='subsystem' type='pci' managed='yes'> + <source> + <address domain='0x0000' bus='0xdb' slot='0x0' function='0x0'/> + </source> + </hostdev> + + * attach the device described in the file to your guest + $ virsh attach-device <guestname> <filename> + + * Without the fix this will fail due to an apparmor block to + /dev/vfio/vfio. With the fix it will work (be aware that many systems + have crappy iommu's still, since I don't know the testers system lets + say it won't fail due to this - I already tested on systems known to be + good and it worked as expected). + + * can be tested from PPA build at https://launchpad.net/~ci-train-ppa- + service/+archive/ubuntu/3292 + + [Regression Potential] + + * This is opening up one more path to the guest, there is no regression + that will block the guest from running. + * If anything I could think of people being concerned this might regress + isolation, but please realize we do not open up a device /dev/vfio/[0- + 9]* instead just the container management node. This is rather safe per + kernel doc and does not allow to access any device (it only allows to + request a new vfio group by opening it). + + [Other Info] + + * n/a + + --- + VFIO is currently leaving an edge case that can kill PCI Hotplug. There are these things in place: 1. if a guest spec has a hostdev it will add - /dev/vfio/vfio - /dev/vfio/[0-9]* - This works fine + /dev/vfio/vfio + /dev/vfio/[0-9]* + This works fine 2. If a device is hotplugged the custom vfio addr is resolved and added - to the per-guest profile as per-device entry like - "/dev/vfio/162" rwk - This works fine and is even better since at this time it can deternine just the device it needs + to the per-guest profile as per-device entry like + "/dev/vfio/162" rwk + This works fine and is even better since at this time it can deternine just the device it needs But #2 needs /dev/vfio/vfio access before knowing any of that. That leads to the case that if one has one hostdev, he can plug more and be fine. But without any hostdev in the initial description the guest will not be allowed to access /dev/vfio/vfio which is needs to determine the indifidual entry. Due to that it completely fails and it can't be hotplugged. Per https://www.kernel.org/doc/Documentation/vfio.txt the base /dev/vfio/vfio is safe and is not an attach vector. So we should allow /dev/vfio/vfio in general.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1775777 Title: allow /dev/vfio/vfio in general To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1775777/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
