qemu: Explain mlock limit size more in detail

Based on Alex's explanation [1] in the recent discussion let's update
the comment explaining the memory lock limit calculation.

[1]
http://www.redhat.com/archives/libvir-list/2015-November/msg00329.html

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 516df17ebbddb42e4b2ef58a3bcaea59d776bcde..3d2b7a0c9682270237d12ea0491a6a0fc97d4885 100644 (file)
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -3645,9 +3645,24 @@ qemuDomainGetMlockLimitBytes(virDomainDefPtr def)
         goto done;
     }
 
-    /* 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). */
+    /* For device passthrough using VFIO the guest memory and MMIO memory
+     * regions need to be locked persistent in order to allow DMA.
+     *
+     * Currently the below limit is based on assumptions about the x86 platform.
+     *
+     * The chosen value of 1GiB below originates from x86 systems where it was
+     * used as space reserved for the MMIO region for the whole system.
+     *
+     * On x86_64 systems the MMIO regions of the IOMMU mapped devices don't
+     * count towards the locked memory limit since the memory is owned by the
+     * device. Emulated devices though do count, but the regions are usually
+     * small. Although it's not guaranteed that the limit will be enough for all
+     * configurations it didn't pose a problem for now.
+     *
+     * http://www.redhat.com/archives/libvir-list/2015-November/msg00329.html
+     *
+     * Note that this may not be valid for all platforms.
+     */
     memKB = virDomainDefGetMemoryActual(def) + 1024 * 1024;
 
  done: