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

[Daniel Henrique Barboza]

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