Re: QOM address space handling

[Eduardo Habkost <ehabkost@redhat.com>]

On Tue, Nov 10, 2020 at 12:46:48PM -0500, Eduardo Habkost wrote:
> On Tue, Nov 10, 2020 at 04:08:16PM +0100, Paolo Bonzini wrote:
> > On 10/11/20 16:03, Eduardo Habkost wrote:
> > > > Does anyone have any arguments for which solution is preferred?
> > > I'd say (2) is preferred, as we don't expect object_new(T) to
> > > have any side effects outside the object instance state.
> > 
> > Since there are no listeners, the side effects of address_space_init() are
> > relatively limited.  So doing it in instance_init is not a big deal.
> > 
> > > Most
> > > address_space_init() calls in the code today seem to be in
> > > realize functions.
> > > 
> > > However, I wonder if we could make this simpler (and mistakes
> > > less fatal) if we make AddressSpace a QOM child of the device.
> > > Paolo, would it be too much overhead to make AddressSpace a QOM
> > > object?
> > 
> > No, it wouldn't.  AddressSpace is already quite heavyweight.
> 
> I thought this was going to be an easy job, but call_rcu()
> requires rcu_head to be the first struct field.  I assume it is
> acceptable to use call_rcu1() + container_of() manually in this
> case.

Wait.  What exactly prevents callers of address_space_destroy()
from freeing the area containing the AddressSpace struct before
do_address_space_destroy() gets a chance to be called?

-- 
Eduardo