From 3d2c6bc59a4cfb28b94a46d11484ec7a4562716c Mon Sep 17 00:00:00 2001 Message-Id: <3d2c6bc59a4cfb28b94a46d11484ec7a4562716c.1377873642.git.jdenemar@redhat.com> From: Michal Privoznik Date: Mon, 26 Aug 2013 17:41:49 +0200 Subject: [PATCH] qemuBuildCommandLine: Fall back to mem balloon if there's no hard_limit https://bugzilla.redhat.com/show_bug.cgi?id=1001143 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_balloon. (cherry picked from commit a7f94a40bb2554c56d0c6bea98a5843690dc3933) --- 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 7bbfd03..6dfd141 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -9239,8 +9239,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.3.2