| 2018-06-08 07:04:25 |
Christian Ehrhardt |
bug |
|
|
added bug |
| 2018-06-08 07:04:30 |
Christian Ehrhardt |
libvirt (Ubuntu): status |
New |
Triaged |
|
| 2018-06-08 07:04:39 |
Christian Ehrhardt |
tags |
|
libvirt-18.10 |
|
| 2018-06-12 14:17:12 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-06-12 14:17:12 |
Christian Ehrhardt |
bug task added |
|
libvirt (Ubuntu Bionic) |
|
| 2018-06-12 14:17:21 |
Christian Ehrhardt |
libvirt (Ubuntu Bionic): status |
New |
Triaged |
|
| 2018-06-12 17:41:52 |
Launchpad Janitor |
libvirt (Ubuntu): status |
Triaged |
Fix Released |
|
| 2018-06-13 09:20:13 |
Christian Ehrhardt |
description |
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
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
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. |
[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
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
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. |
|
| 2018-06-13 11:45:50 |
Robie Basak |
libvirt (Ubuntu Bionic): status |
Triaged |
Fix Committed |
|
| 2018-06-13 11:45:52 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-06-13 11:45:54 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2018-06-13 11:45:57 |
Robie Basak |
tags |
libvirt-18.10 |
libvirt-18.10 verification-needed verification-needed-bionic |
|
| 2018-06-14 06:35:35 |
Christian Ehrhardt |
tags |
libvirt-18.10 verification-needed verification-needed-bionic |
libvirt-18.10 verification-done verification-done-bionic |
|
| 2018-06-21 07:55:19 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-06-21 07:55:17 |
Launchpad Janitor |
libvirt (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
