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