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

[Erik Skultety]

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