qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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


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