[libvirt] [PATCH v2 0/7] Memory locking limit improvements

Andrea Bolognani abologna at redhat.com
Fri Dec 11 14:45:31 UTC 2015


During my testing, I've realized that even with the series applied
there's still one case in which we're unable to restore the previous
memory locking limit after removing the last PCI hostdev from the guest.

If an x86 guest contains a PCI hostdev in its XML definition, then the
memory locking limit will be set correctly, but virCommandGetMaxMemLock()
will be used instead of virProcessGetMaxMemLock(), and the limit will be
set right before calling exec() to spawn the qemu binary.

In this context, we have no access to the virDomainObj or even
virDomainDef instances, so I see no way of storing the original limit
for later retrieval.

The series is still an improvement as it covers all other cases. Still,
I thought this was worth mentioning.

Changes since v1[1]:

  * reorder commits according to John's suggestions
  * don't fail if we can't retrieve the current memory locking limit
  * small changes here and there as pointed out during review

Cheers.


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

Andrea Bolognani (7):
  process: Allow virProcessPrLimit() to get current limit
  process: Add virProcessGetMaxMemLock()
  qemu: Add qemuDomainAdjustMaxMemLock()
  qemu: Use qemuDomainAdjustMaxMemLock()
  qemu: Reduce memlock limit after detaching PCI hostdev
  qemu: Allow qemuDomainAdjustMaxMemLock() to restore previous value
  qemu: Replace Mlock with MemLock in function names

 configure.ac             |  2 +-
 src/conf/domain_conf.h   |  3 +++
 src/libvirt_private.syms |  1 +
 src/qemu/qemu_command.c  |  4 ++--
 src/qemu/qemu_domain.c   | 53 ++++++++++++++++++++++++++++++++++++++---
 src/qemu/qemu_domain.h   |  5 ++--
 src/qemu/qemu_hotplug.c  | 45 ++++++++++++++---------------------
 src/util/virprocess.c    | 61 +++++++++++++++++++++++++++++++++++++++++++-----
 src/util/virprocess.h    |  2 ++
 9 files changed, 135 insertions(+), 41 deletions(-)

-- 
2.5.0




More information about the libvir-list mailing list