On 7/18/19 5:48 AM, Michal Privoznik wrote:
On 7/18/19 8:46 AM, Michal Privoznik wrote:
On 7/17/19 7:20 PM, Daniel Henrique Barboza wrote:
After this commit, QEMU domains with PCI hostdevs running with
managed=true started to fail to launch with the following error:
error : virProcessRunInFork:1170 : internal error: child reported
(status=125): unable to open /dev/vfio/1: Device or resource busy
One way to avoid this issue is to disable this new feature
in qemu.conf, setting remember_owner=0. However, given that
this feature is enabled by default and it is breaking domains that
were running before it, it is best to revert the change until
it is fixed for this scenario as well.
Well, ideally, we want the feature to be turned on by default, just
like namespaces for instance. I've temporarily disabled the feature
back in the day because we were close to release and it turned out
the feature was not ready. But now there is still plenty of time to
fix it.
Anyway, I'll investigate. Meanwhile, can you share your <hostdev/>
config or even better the full domain definition please?
Okay, so I think I know what is going on. You have two <hostdev/>-s in
your domain and both of them belong to the same IOMMU group, right?
Yes. I forgot to mention that in this reversal patch, sorry. The error
is reproduced
with a VM using a PCI Multifunction card - alll 4 functions in the IOMMU
group 1.
I'll test your already proposed fix in a few moments. Just need a hit of
coffee first :)
Thanks,
DHB
If that is the case, then the same path appears twice in the list of
paths passed to virSecurityManagerMetadataLock(). For instance, in my
case:
Thread 2.1 "libvirtd" hit Breakpoint 3, virSecurityManagerMetadataLock
(mgr=0x7f365c026660, paths=0x7f36a001c1e0, npaths=6) at
security/security_manager.c:1283
1283 {
virSecurityManagerMetadataLock 1 # p *paths@npaths
$6 = {0x7f36a0027720 "/var/lib/libvirt/images/fedora.qcow2",
0x7f36a001a660 "/var/lib/libvirt/images/fd.img",
0x7f36a001c470
"/dev/disk/by-path/ip-10.37.132.232:3260-iscsi-iqn.2017-03.com.mprivozn:server-lun-1",
0x7f36a00262b0 "/dev/vfio/9",
0x7f36a0025e20 "/dev/vfio/9",
0x7f36a001d880
"/var/lib/libvirt/qemu/channel/target/domain-1-fedora/org.qemu.guest_agent.0"}
The "/dev/vfio/9" path is there twice because I have this graphics
card that has two functions and I'm passing them both into the domain.
The problem here is that when virSecurityManagerMetadataLock() gets to
first /dev/vfio/9 path, it opens it and locks it. Then it wants to
process the next path (which is the same path), but it fails
open()-ing the path, because it's locked. Honestly, I don't know if
that is expected behaviour, but even it if wasn't then we would fail
to lock the path second time. I'm proposing a fix in no time.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
