[libvirt] [PATCH] qemuBuildCommandLine: Fall back to mem balloon if there's no hard_limit
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. --- 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); + } virObjectUnref(cfg); return cmd; -- 1.8.1.5
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
On 08/20/2013 03:06 PM, 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.
You forgot about the bookkeepers, didn't you?
--- 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); + }
16bcb3b "qemu: Drop qemuDomainMemoryLimit" also changed the MemLock limit in qemuDomainAttachHostPciDevice, I think we need yet another patch :( Jan
participants (3)
-
Eric Blake -
Ján Tomko -
Michal Privoznik