[libvirt] [PATCH] qemuBuildCommandLine: Fall back to mem balloon if there's no hard_limit

Eric Blake eblake at redhat.com
Tue Aug 20 13:15:25 UTC 2013


On 08/20/2013 07:06 AM, Michal Privoznik wrote:
> If there's no hard_limit set and domain uses VFIO we still must lock the
> guest memory (prerequisite from qemu). Hence, we should compute the
> amount to be locked from max_baloon.

s/baloon/balloon/

> ---
>  src/qemu/qemu_command.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index c8f7df2..71c220f 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -9219,8 +9219,19 @@ qemuBuildCommandLine(virConnectPtr conn,
>          goto error;
>      }
>  
> -    if (mlock)
> -        virCommandSetMaxMemLock(cmd, def->mem.hard_limit * 1024);
> +    if (mlock) {
> +        unsigned long long memKB;
> +
> +        /* VFIO requires all of the guest's memory to be
> +         * locked resident, plus some amount for IO
> +         * space. Alex Williamson suggested adding 1GiB for IO
> +         * space just to be safe (some finer tuning might be
> +         * nice, though).
> +         */
> +        memKB = def->mem.hard_limit ?
> +            def->mem.hard_limit : def->mem.max_balloon + 1024 * 1024;
> +        virCommandSetMaxMemLock(cmd, memKB * 1024);

If I'm understanding correctly, this is how much memory can be locked,
but the domain can use more (unlocked) memory as needed.  Locked memory
corresponds to what the guest sees, whereas the OOM-killer on hard-limit
was kicking in when qemu itself allocated memory not visible to the
guest.  Therefore, this is not presenting the same risk for OOM-killer
as the other hard_limit hueristic was.  ACK.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130820/1838dfb5/attachment-0001.sig>


More information about the libvir-list mailing list