[Top][All Lists]

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

Re: Purpose of QOM properties registered at realize time?

From: Peter Maydell
Subject: Re: Purpose of QOM properties registered at realize time?
Date: Wed, 7 Oct 2020 15:28:52 +0100

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".

(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.)

> 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

reply via email to

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