Re: [libvirt] [PATCH 5/6] qemu: Reduce memlock limit after detaching hostdev

On Wed, 2015-12-09 at 15:15 -0500, John Ferlan wrote: > On 11/24/2015 08:56 AM, Andrea Bolognani wrote: >> We increase the limit before plugging in a PCI hostdev or a memory >> module because some memory might need to be locked due to eg. VFIO. >> >> Of course we should do the opposite after unplugging a device: this >> was already the case for memory modules, but not for hostdevs. >> --- >> src/qemu/qemu_hotplug.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c >> index a5c134a..04baeff 100644 >> --- a/src/qemu/qemu_hotplug.c >> +++ b/src/qemu/qemu_hotplug.c >> @@ -3070,6 +3070,12 @@ qemuDomainRemoveHostDevice(virQEMUDriverPtr driver, >> networkReleaseActualDevice(vm->def, net); >> virDomainNetDefFree(net); >> } >> + >> + /* QEMU might no longer need to lock as much memory, eg. we just detached >> + * a VFIO device, so adjust the limit here */ >> + if (qemuDomainAdjustMaxMemLock(vm) < 0) >> + VIR_WARN("Failed to adjust locked memory limit"); >> + >> ret = 0; >> >> cleanup: >> > > Since the add was in qemuDomainAttachHostPCIDevice, why is the remove > not in qemuDomainDetachHostPCIDevice? Doing it here would mean it's > call for any host device removal - whether or not it was ever added. Because qemuDomainDetachHostPCIDevice() is where we ask for the device to be removed from the guest, but we have to wait for it to actually be removed (and for the guest definition to be updated) before changing the memory locking limit. I guess I could move this code to qemuDomainDetachThisHostDevice(), but keeping it close to where the guest definition is updated looks cleaner to me.

I also fail to see how a device that was never added could be removed, could you please elaborate?