Re: [libvirt] running Libvirt from source code, IPC_LOCK and VFIO
On Mon, Feb 04, 2019 at 08:44:21PM -0200, Daniel Henrique Barboza wrote:
Hi Erik,
Just to let you know that the error I reported in one of my replies was
being caused by one change I forgot to undo. This error here:
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
was happening because I have commented out this line inside
qemu_capabilities.c:
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -4519,7 +4519,7 @@
virQEMUCapsInitQMPCommandRun(virQEMUCapsInitQMPCommandPtr cmd,
"-daemonize",
NULL);
virCommandAddEnvPassCommon(cmd->cmd);
- virCommandClearCaps(cmd->cmd);
+ // virCommandClearCaps(cmd->cmd);
#if WITH_CAPNG
/* QEMU might run into permission issues, e.g. /dev/sev (0600),
override
Thus there is no need to move the PR_CAP_AMBIENT around to prevent the
error message. Sorry for any alarms I might have raised there.
Well, at least it doesn't create even more confusion :). Still, you said you
were running libvirtd root and yet you experience the error which I still don't
understand, it's like capng_apply failed on Power and therefore you don't have
DAC_OVERRIDE in any of the sets which prctl relies on OR prctl's constraints
differ from x86 and indeed having a cap in the PERMITTED && INHERITED sets is
not enough. I'm sorry I can't help more here as I don't have a Power machine.
I'm still experiencing the issue with IPC_LOCK inside the guest though. I'll
update
here when I have concrete findings about it.
This is tricky, ideally, we wouldn't want every QEMU to have the IPC_LOCK
capability (IMHO none of them should), but IIUC we don't know where the
device's memory will be mapped and therefore from DMA's POV we don't know
which
regions to lock (we can only lock the whole memory + 1GB for any future VFIO
devices), am I right?
Erik