On 05/17/2013 09:03 AM, Jiri Denemark wrote:
> If a domain is configured to have all its memory locked, we need to
> increase RLIMIT_MEMLOCK so that QEMU is actually allowed to lock the
> memory.
> ---
> src/qemu/qemu_command.c | 31 +++++++++++++++++++++----------
> 1 file changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index c268a3a..8e2de09 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -6440,6 +6440,7 @@ qemuBuildCommandLine(virConnectPtr conn,
> int spice = 0;
> int usbcontroller = 0;
> bool usblegacy = false;
> + bool mlock;
> int contOrder[] = {
> /* We don't add an explicit IDE or FD controller because the
> * provided PIIX4 device already includes one. It isn't possible to
> @@ -6551,6 +6552,7 @@ qemuBuildCommandLine(virConnectPtr conn,
> virCommandAddArgFormat(cmd, "mlock=%s",
> def->mem.locked ? "on" : "off");
> }
> + mlock = def->mem.locked;
>
> virCommandAddArg(cmd, "-smp");
> if (!(smp = qemuBuildSmpArgStr(def, qemuCaps)))
> @@ -8191,22 +8193,13 @@ qemuBuildCommandLine(virConnectPtr conn,
>
> if (hostdev->source.subsys.u.pci.backend
> == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO) {
> - unsigned long long memKB;
> -
> if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VFIO_PCI)) {
> virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> _("VFIO PCI device assignment is not "
> "supported by this version of qemu"));
> goto error;
> }
> - /* 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).
> - */
I think it would be good to retain a short comment here, maybe just
"VFIO requires all guest memory and IO space to be locked in RAM".
> - memKB = def->mem.max_balloon + (1024 * 1024);
> - virCommandSetMaxMemLock(cmd, memKB * 1024);
> + mlock = true;
> }
>
> if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE)) {
> @@ -8425,6 +8418,24 @@ qemuBuildCommandLine(virConnectPtr conn,
> goto error;
> }
>
> + 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).
> + *
> + * If memory hard_limit is configured, we can use it directly as
> + * there is no sense to set MEMLOCK limit beyond it. Also we can
> + * safely use it instead of any magically computed value.
Does the setting of hard_limit take IO space into account?
And what about the memory of the qemu process itself?
Note that there is another place where virProcessSetMaxMemLock() is
called (qemuDomainAttachHostPciDevice()). To be consistent, we should
use the same logic there as here. Unfortunately, one calls
virCommandSetMaxMemLock() (to set it in the future after the
as-yet-uncreated process is running), and the other sets it immediately
in an already running process, so if it's turned into a utility
function, it has to be a function that takes a virDomainDef and returns
the proper amount to lock. Not sure what that would be called...
> + */
> + if (def->mem.hard_limit)
> + memKB = def->mem.hard_limit;
> + else
> + memKB = def->mem.max_balloon + (1024 * 1024);
> + virCommandSetMaxMemLock(cmd, memKB * 1024);
> + }
> +
> virObjectUnref(cfg);
> return cmd;
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list