Re: Purpose of QOM properties registered at realize time?

[Eduardo Habkost]

On Wed, Oct 07, 2020 at 03:28:52PM +0100, Peter Maydell wrote:
> On Tue, 6 Oct 2020 at 23:06, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > While trying to understand how QOM properties are used in QEMU, I
> > stumbled upon multiple cases where alias properties are added at
> > realize time.
> >
> > Now, I don't understand why those properties exist.  As the
> > properties are added at realize time, I assume they aren't
> > supposed to be touched by the user at all.  If they are not
> > supposed to be touched by the user, what exactly is the purpose
> > of those QOM properties?
> 
> QOM properties are not solely provided for the benefit of the user.
> We also use them a lot in board and SoC code as the interface
> by which C code says "create an object, configure it, connect it".
> 

Right.  I'm trying to get a better understand of how exactly QOM
is used internally when it's not user-visible.  Not being able to
distinguish internal and external usage when looking at the code
makes it very difficult to clean up external QOM-based
interfaces.


> (This was partly motivated in the original QOM design I think by the idea
> being that eventually one might be able to completely define a board model
> purely declaratively by specifying all the devices and properties and
> wiring everything up that way. Needless to say we've never really
> taken any serious steps towards actually doing that.)

Thanks for the explanation.

Now, how do I locate the code that depends on those QOM
properties to work?  When the property name is visible in the
code, I can grep for the property name.  But I don't know how to
find users of the GPIOs exposed by qdev_pass_gpios().

> 
> > For reference, these are the cases I've found:
> >
> > $ git grep -nwpE 
> > 'object_property_add_alias|qdev_pass_gpios|qdev_alias_all_properties' | 
> > grep -A1 realize
> > hw/arm/allwinner-a10.c=71=static void aw_a10_realize(DeviceState *dev, 
> > Error **errp)
> > hw/arm/allwinner-a10.c:89:    qdev_pass_gpios(DEVICE(&s->intc), dev, NULL);
> 
> This kind of thing, and also the sd-bus cases, is where an SoC device wants
> to expose some GPIO lines or an sd-bus which is actually implemented by
> a device which exists inside the SoC (and which the SoC has created and
> wired up). The effect is that for the user of the SoC object the gpio/sd-bus
> can be used as if it was directly implemented by the SoC object, when it's
> actually just being passed through to the internal device.
> 
> I'd have to look at the code to find out whether it's really necessary in all
> cases to do this pass-through setup at realize rather than instance-init.
> 
> In this case:
> 
> > hw/arm/armv7m.c=149=static void armv7m_realize(DeviceState *dev, Error 
> > **errp)
> > hw/arm/armv7m.c:219:    qdev_pass_gpios(DEVICE(&s->nvic), dev, NULL);
> 
> there's a comment on the immediately preceding lines which explains what
> the code is doing and why it is being done in realize:
> 
>  215     /* Alias the NVIC's input and output GPIOs as our own so the board
>  216      * code can wire them up. (We do this in realize because the
>  217      * NVIC doesn't create the input GPIO array until realize.)
>  218      */
> 
> Possibly one could move the code in the devices which creates the
> GPIO array/sdbus/whatever so that it does so in instance_init
> rather than in realize, and then more of these "alias a connection
> through" bits of code could also move to instance_init. But there are
> cases where the GPiO/etc can only be created in realize because
> the number of GPIOs depends on properties of the device and so isn't
> know at instance_init time.
> 
> -- PMM
> 

-- 
Eduardo