From: Peter Maydell <peter.maydell@linaro.org>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "open list:RISC-V" <qemu-riscv@nongnu.org>,
QEMU Developers <qemu-devel@nongnu.org>,
qemu-arm <qemu-arm@nongnu.org>, qemu-ppc <qemu-ppc@nongnu.org>,
Paolo Bonzini <pbonzini@redhat.com>,
"Daniel P. Berrange" <berrange@redhat.com>,
John Snow <jsnow@redhat.com>
Subject: Re: Purpose of QOM properties registered at realize time?
Date: Wed, 7 Oct 2020 15:28:52 +0100 [thread overview]
Message-ID: <CAFEAcA_se7jErv9AFM2D7UdDMurB9Lb6W9aAXD6648spQ6idKg@mail.gmail.com> (raw)
In-Reply-To: <20201006220647.GR7303@habkost.net>
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
next prev parent reply other threads:[~2020-10-07 14:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 22:06 Purpose of QOM properties registered at realize time? Eduardo Habkost
2020-10-07 10:35 ` BALATON Zoltan via
2020-10-07 12:04 ` Paolo Bonzini
2020-10-07 13:02 ` Eduardo Habkost
2020-10-07 13:55 ` Paolo Bonzini
2020-10-07 14:27 ` Eduardo Habkost
2020-10-07 14:54 ` Paolo Bonzini
2020-10-07 15:51 ` Eduardo Habkost
2020-10-07 15:58 ` Peter Maydell
2020-10-07 14:28 ` Peter Maydell [this message]
2020-10-07 15:48 ` Eduardo Habkost
2020-10-08 9:45 ` Markus Armbruster
2020-10-08 10:00 ` Peter Maydell
2020-10-08 15:15 ` Eduardo Habkost
2020-10-08 15:41 ` Peter Maydell
2020-10-12 10:30 ` Mark Cave-Ayland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFEAcA_se7jErv9AFM2D7UdDMurB9Lb6W9aAXD6648spQ6idKg@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=jsnow@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-riscv@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).