From 3d2c6bc59a4cfb28b94a46d11484ec7a4562716c Mon Sep 17 00:00:00 2001
Message-Id: <3d2c6bc59a4cfb28b94a46d11484ec7a4562716c.1377873642.git.jdenemar@redhat.com>
From: Michal Privoznik <mprivozn@redhat.com>
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