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

[Michal Privoznik]

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?
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 at 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