qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/9] qom: improve reference counting and hot


From: Vasilis Liaskovitis
Subject: Re: [Qemu-devel] [RFC PATCH 0/9] qom: improve reference counting and hotplug
Date: Tue, 9 Oct 2012 19:15:31 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi,

On Sun, Aug 26, 2012 at 10:51:29AM -0500, Anthony Liguori wrote:
> Right now, you need to pair up object_new with object_delete.  This is
> impractical when using reference counting because we would like to ensure that
> object_unref() also frees memory when needed.
> 
> The first few patches fix this problem by introducing a release callback so
> that objects that need special release behavior (i.e. g_free) can do that.
> 
> Since link and child properties all hold references, in order to actually free
> an object, we need to break those links.  User created devices end up as
> children of a container.  But child properties cannot be removed which means
> there's no obvious way to remove the reference and ultimately free the object.
> 
> We introduce the concept of "nullable child" properties to solve this.  This 
> is
> a child property that can be broken by writing NULL to the child link.  Today
> we set all /peripheral* children to be nullable so that they can be deleted by
> management tools.
> 
> In terms of modeling hotplug, we represent unplug by removing the object from
> the parent bus.  We need to register a notifier for when this happens so that
> we can also remove the parent's child property to ultimately release the 
> object.
> 
> Putting it all together, we have:
> 
> 1) qmp_device_del will issue a callback to a device.  The default callback 
> will
>    do a forced eject (which means writing NULL to the parent_bus link).
> 
> 2) PCI hotplug is a bit more sophisticated in that it waits for the guest to
>    do the ejection.
> 
> 3) qmp_device_del will register an eject notifier such that the device gets
>    completely removed.
> 
> There's a slightly change in behavior here.  A device is not automatically
> destroyed based on a guest initiated eject.  A management tool must explicitly
> break the parent's link to the child in order for the device to disappear
> completely.  device_del behaves exactly as it does today though.

is there a plan to respin this series, or has it been dropped? Afaict it hasn't
landed upstream. I am reworking an acpi memory hotplug RFC patchset, and 
noticed this
patchset changes guest-initiated eject semantics. 

Currently a successfull guest-initiated eject in my mem-hotplug patchset 
destroys the
qdev device. But the semantics of this patchset would require a new behaviour.

thanks,

- Vasilis



reply via email to

[Prev in Thread] Current Thread [Next in Thread]