Re: [libvirt] [PATCH v2 1/3] qemu: Extract logic to determine the mlock limit size for VFIO
On Mon, Nov 09, 2015 at 13:09:59 -0500, John Ferlan wrote:
On 11/09/2015 07:50 AM, Peter Krempa wrote:
> New function qemuDomainGetMlockLimitBytes will now handle the
> calculation so that it unifies the logic to one place and allows later
> reuse.
> ---
[...]
> +/**
> + * qemuDomainGetMlockLimitBytes:
> + *
> + * @def: domain definition
> + *
> + * Returns the size of the memory in bytes that needs to be set as
> + * RLIMIT_MEMLOCK for purpose of VFIO device passthrough. In cases where
> + * mem.hard_limit is set, the value is preferred,otherwise the value may depend
> + * on the device or architecture.
How about?
Returns the size of memory in bytes to allow a process (domain) to be
That satement would be misleading. The size returned by this function
may not be enough to lock the complete process into RAM. Locking the
complete process would also include disk buffers, the binary itself and
other overhead of the process itself. This function clearly isn't
designed to do that.
Said that, it is actually used that way, since the botched revert of
qemuDomainMemoryLimit. Although I would like to remove that I'm afraid I
can't really do that, since it would break VMs that use locked memory
backing. It's wrong to use it that way though and I want to discourage
it, but I really don't want to break existing configs.
At this point I'd like to limit this to pure code extraction for reuse
without sliping into anything leading to further misuse of this
function. By the way, that was the original reason for not adding a
comment at all.
locked into RAM (e.g setrlimit RLIMIT_MEMLOCK). If a mem.hard_limit
is
Since this is a qemu specific function setrlimit(RLIMIT_MEMLOCK, ...) is
actually the only impl.
set, then that value is preferred; otherwise, the value returned may
depend upon the architecture or devices present, such as a VFIO
passthrough device.
Peter
Attachments:
- signature.asc (application/pgp-signature — 819 bytes)