Re: [PATCH 1/1] Revert "Revert "qemu: Temporary disable owner remembering""

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux