allow /dev/vfio/vfio in general
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| libvirt (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
| Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
[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:/
[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/
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
"/
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:/
| Changed in libvirt (Ubuntu): | |
| status: | New → Triaged |
| tags: | added: libvirt-18.10 |
| Christian Ehrhardt (paelzer) wrote | #1 |
| Christian Ehrhardt (paelzer) wrote | #2 |
| Christian Ehrhardt (paelzer) wrote | #3 |
| Changed in libvirt (Ubuntu Bionic): | |
| status: | New → Triaged |
| Christian Ehrhardt (paelzer) wrote | #4 |
| Launchpad Janitor (janitor) wrote | #5 |
| Changed in libvirt (Ubuntu): | |
| status: | Triaged → Fix Released |
| description: | updated |
| Christian Ehrhardt (paelzer) wrote | #6 |
| Robie Basak (racb) wrote Please test proposed package | #7 |
| Changed in libvirt (Ubuntu Bionic): | |
| status: | Triaged → Fix Committed |
| tags: | added: verification-needed verification-needed-bionic |
| Christian Ehrhardt (paelzer) wrote | #8 |
| Christian Ehrhardt (paelzer) wrote | #9 |
| tags: |
added: verification-done verification-done-bionic removed: verification-needed verification-needed-bionic |
| Launchpad Janitor (janitor) wrote | #11 |
| Changed in libvirt (Ubuntu Bionic): | |
| status: | Fix Committed → Fix Released |
| Łukasz Zemczak (sil2100) wrote Update Released | #10 |
I did some history on this as we had that in the past.
We had it for bug 1678322
But then in a discussion around upstreaming dropped it https:/
What we missed back then is this:
A) system has hostdev in initial guest, virt-aa-helper adds /dev/vfio/vfio and all works
B) as A, but later one does hotplug with such a device - still works
C) the initial system has no hostdev, so virt-aa-helper adds no rule
But if on (c) later hotplug is done it will break as it will need to access /dev/vfio/vfio
before it knows anything.
The actual per device rule is added to the guest which is all the isolation we want.
Now one could try to find the spot in BEFORE the guest needs /dev/vfio/vfio and add it to the guest profile then. But I haven't found it and until one can spend more time on this we need to bring the static rule back.
After all /dev/vfio/vfio is safe to be shared.
So I don't mind if someone codes up a long term dynamic vfio access, but for now add the line to un-break case (C).