[libvirt] running Libvirt from source code, IPC_LOCK and VFIO

[Daniel Henrique Barboza]

On 2/4/19 6:47 AM, Yuval Shaia wrote:
> On Fri, Feb 01, 2019 at 07:40:36PM -0200, Daniel Henrique Barboza wrote:
>> Update: I've figured it out.
>>
>> The bug here was that, even running as root, I was getting errors like:
>>
>> error : virQEMUCapsNewForBinaryInternal:4687 : internal error: Failed to
>> probe QEMU binary with
>> QMP: libvirt:  error : prctl failed to enable 'dac_override' in the AMBIENT
>> set:
>> Operation not permitted
>>
>> The reason is that the host has libcap-ng installed. ./configure uses it if
>> available,
>> setting WITH_CAPNG in the code. I am unsure if this has something to do with
>> the libcap-ng configuration in this system I'm using or if there is
>> something
>> missing in the Libvirt code, but the spawned QEMU process isn't inheriting
>> the
>> capabilities it should have.
>>
>> Disabling support of this lib with "--with-capng=no" in autogen.sh and
>> rebuilding Libvirt fixed the problem. I was even able to see more NUMA
>> nodes than I was before using the system libvirt (which is the original
>> bug I am/was investigating).
>>
>>
>> Thanks!
>>
> Hey Daniel,
> I had the same problem with Mellanox RDMA device as backend for pvrdma
> device where the mlx5 driver also enforces CAP_IPC_LOCK.
>
> So at first i use this as a workaround but i knew that it is not a final
> approach as it makes a wrong use of memory.
> <memoryBacking>
>    <locked/>
> </memoryBacking>
>
> Anyways, your tip helps so wanted to say thanks!

No problem! Thanks for sharing your memoryBacking workaround.




DHB






>
> Yuval
>
>>
>>
>>
>> On 2/1/19 4:04 PM, Daniel Henrique Barboza wrote:
>>> Hi,
>>>
>>> I'm facing a strange behavior when running Libvirt from source code,
>>> latest upstream, on an Ubuntu 18.04.1 LTS Power 9 server. My QEMU
>>> guest - which is using VFIO and GPU passthrough - breaks on boot when
>>> trying to allocate a DMA window inside KVM.
>>>
>>> Debugging the code, I've found out that the problem is related to the
>>> process
>>> not having CAP_IPC_LOCK - at least from the host kernel perspective.
>>>
>>> This is strange because:
>>>
>>> - the same VM running directly from QEMU command line works
>>> - the same VM running in the system Libvirt (v4.0.0, Ubuntu version)
>>> also works
>>>
>>> What am I missing? My understanding on Linux process is that a process
>>> running as root should inherit the same capabilities of the user, which
>>> includes
>>> CAP_IPC_LOCK. Running Libvirt from source code should grant ipc_lock
>>> to it ... right?
>>>
>>>
>>>
>>> Any help is appreciated. I can provide more details (VM XML for example)
>>> if necessary.
>>>
>>>
>>> Thanks!
>> --
>> libvir-list mailing list
>> libvir-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list