|
 |
38f2fd |
From 02482db69537daa5a1235db00ece500fd7e1844d Mon Sep 17 00:00:00 2001
|
|
|
38f2fd |
Message-Id: <02482db69537daa5a1235db00ece500fd7e1844d@dist-git>
|
|
|
38f2fd |
From: Peter Krempa <pkrempa@redhat.com>
|
|
|
38f2fd |
Date: Thu, 12 Nov 2015 08:40:45 +0100
|
|
|
38f2fd |
Subject: [PATCH] qemu: Explain mlock limit size more in detail
|
|
|
38f2fd |
|
|
|
38f2fd |
https://bugzilla.redhat.com/show_bug.cgi?id=1280420
|
|
|
38f2fd |
|
|
|
38f2fd |
Based on Alex's explanation [1] in the recent discussion let's update
|
|
|
38f2fd |
the comment explaining the memory lock limit calculation.
|
|
|
38f2fd |
|
|
|
38f2fd |
[1]
|
|
|
38f2fd |
http://www.redhat.com/archives/libvir-list/2015-November/msg00329.html
|
|
|
38f2fd |
|
|
|
38f2fd |
(cherry picked from commit 63ed05d2410bfb9179b26bc3422ea5f9b546d7b3)
|
|
|
38f2fd |
|
|
|
38f2fd |
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
|
|
|
38f2fd |
---
|
|
|
38f2fd |
src/qemu/qemu_domain.c | 21 ++++++++++++++++++---
|
|
|
38f2fd |
1 file changed, 18 insertions(+), 3 deletions(-)
|
|
|
38f2fd |
|
|
|
38f2fd |
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
|
|
|
38f2fd |
index fd4449d..be3dcf6 100644
|
|
|
38f2fd |
--- a/src/qemu/qemu_domain.c
|
|
|
38f2fd |
+++ b/src/qemu/qemu_domain.c
|
|
|
38f2fd |
@@ -3445,9 +3445,24 @@ qemuDomainGetMlockLimitBytes(virDomainDefPtr def)
|
|
|
38f2fd |
goto done;
|
|
|
38f2fd |
}
|
|
|
38f2fd |
|
|
|
38f2fd |
- /* VFIO requires all of the guest's memory to be locked resident, plus some
|
|
|
38f2fd |
- * amount for IO space. Alex Williamson suggested adding 1GiB for IO space
|
|
|
38f2fd |
- * just to be safe (some finer tuning might be nice, though). */
|
|
|
38f2fd |
+ /* For device passthrough using VFIO the guest memory and MMIO memory
|
|
|
38f2fd |
+ * regions need to be locked persistent in order to allow DMA.
|
|
|
38f2fd |
+ *
|
|
|
38f2fd |
+ * Currently the below limit is based on assumptions about the x86 platform.
|
|
|
38f2fd |
+ *
|
|
|
38f2fd |
+ * The chosen value of 1GiB below originates from x86 systems where it was
|
|
|
38f2fd |
+ * used as space reserved for the MMIO region for the whole system.
|
|
|
38f2fd |
+ *
|
|
|
38f2fd |
+ * On x86_64 systems the MMIO regions of the IOMMU mapped devices don't
|
|
|
38f2fd |
+ * count towards the locked memory limit since the memory is owned by the
|
|
|
38f2fd |
+ * device. Emulated devices though do count, but the regions are usually
|
|
|
38f2fd |
+ * small. Although it's not guaranteed that the limit will be enough for all
|
|
|
38f2fd |
+ * configurations it didn't pose a problem for now.
|
|
|
38f2fd |
+ *
|
|
|
38f2fd |
+ * http://www.redhat.com/archives/libvir-list/2015-November/msg00329.html
|
|
|
38f2fd |
+ *
|
|
|
38f2fd |
+ * Note that this may not be valid for all platforms.
|
|
|
38f2fd |
+ */
|
|
|
38f2fd |
memKB = virDomainDefGetMemoryActual(def) + 1024 * 1024;
|
|
|
38f2fd |
|
|
|
38f2fd |
done:
|
|
|
38f2fd |
--
|
|
|
38f2fd |
2.6.3
|
|
|
38f2fd |
|