mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-23 06:05:27 +00:00
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
This commit is contained in:
parent
e7b91c510e
commit
63ed05d241
@ -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:
|
||||
|
Loading…
Reference in New Issue
Block a user