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