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?
Cheers.
--
Andrea Bolognani
Software Engineer - Virtualization Team
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
