Purpose of QOM properties registered at realize time?

Purpose of QOM properties registered at realize time?

[Eduardo Habkost]

Hi,

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?

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);
--
hw/arm/allwinner-h3.c=232=static void allwinner_h3_realize(DeviceState *dev, Error **errp)
hw/arm/allwinner-h3.c:359:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->mmc0),
--
hw/arm/armsse.c=429=static void armsse_realize(DeviceState *dev, Error **errp)
hw/arm/armsse.c:1092:    qdev_pass_gpios(dev_secctl, dev, "mscexp_status");
--
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);
--
hw/arm/bcm2835_peripherals.c=128=static void bcm2835_peripherals_realize(DeviceState *dev, Error **errp)
hw/arm/bcm2835_peripherals.c:322:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->gpio), "sd-bus");
--
hw/arm/bcm2836.c=69=static void bcm2836_realize(DeviceState *dev, Error **errp)
hw/arm/bcm2836.c:87:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->peripherals),
hw/arm/msf2-soc.c=79=static void m2sxxx_soc_realize(DeviceState *dev_soc, Error **errp)
hw/arm/msf2-soc.c:170:        object_property_add_alias(OBJECT(s), bus_name,
--
hw/arm/nrf51_soc.c=58=static void nrf51_soc_realize(DeviceState *dev_soc, Error **errp)
hw/arm/nrf51_soc.c:138:    qdev_pass_gpios(DEVICE(&s->gpio), dev_soc, NULL);
--
hw/arm/xlnx-zynqmp.c=276=static void xlnx_zynqmp_realize(DeviceState *dev, Error **errp)
hw/arm/xlnx-zynqmp.c:522:        object_property_add_alias(OBJECT(s), bus_name, sdhci, "sd-bus");
--
hw/misc/mac_via.c=1011=static void mac_via_realize(DeviceState *dev, Error **errp)
hw/misc/mac_via.c:1028:    object_property_add_alias(OBJECT(dev), "irq[0]", OBJECT(ms),
--
hw/ppc/spapr_drc.c=511=static void realize(DeviceState *d, Error **errp)
hw/ppc/spapr_drc.c:530:    object_property_add_alias(root_container, link_name,
hw/riscv/sifive_e.c=186=static void sifive_e_soc_realize(DeviceState *dev, Error **errp)
hw/riscv/sifive_e.c:233:    qdev_pass_gpios(DEVICE(&s->gpio), dev, NULL);
hw/riscv/sifive_u.c=651=static void sifive_u_soc_realize(DeviceState *dev, Error **errp)
hw/riscv/sifive_u.c:743:    qdev_pass_gpios(DEVICE(&s->gpio), dev, NULL);

-- 
Eduardo

Purpose of QOM properties registered at realize time?

[Eduardo Habkost]

Hi,

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?

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);
--
hw/arm/allwinner-h3.c=232=static void allwinner_h3_realize(DeviceState *dev, Error **errp)
hw/arm/allwinner-h3.c:359:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->mmc0),
--
hw/arm/armsse.c=429=static void armsse_realize(DeviceState *dev, Error **errp)
hw/arm/armsse.c:1092:    qdev_pass_gpios(dev_secctl, dev, "mscexp_status");
--
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);
--
hw/arm/bcm2835_peripherals.c=128=static void bcm2835_peripherals_realize(DeviceState *dev, Error **errp)
hw/arm/bcm2835_peripherals.c:322:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->gpio), "sd-bus");
--
hw/arm/bcm2836.c=69=static void bcm2836_realize(DeviceState *dev, Error **errp)
hw/arm/bcm2836.c:87:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->peripherals),
hw/arm/msf2-soc.c=79=static void m2sxxx_soc_realize(DeviceState *dev_soc, Error **errp)
hw/arm/msf2-soc.c:170:        object_property_add_alias(OBJECT(s), bus_name,
--
hw/arm/nrf51_soc.c=58=static void nrf51_soc_realize(DeviceState *dev_soc, Error **errp)
hw/arm/nrf51_soc.c:138:    qdev_pass_gpios(DEVICE(&s->gpio), dev_soc, NULL);
--
hw/arm/xlnx-zynqmp.c=276=static void xlnx_zynqmp_realize(DeviceState *dev, Error **errp)
hw/arm/xlnx-zynqmp.c:522:        object_property_add_alias(OBJECT(s), bus_name, sdhci, "sd-bus");
--
hw/misc/mac_via.c=1011=static void mac_via_realize(DeviceState *dev, Error **errp)
hw/misc/mac_via.c:1028:    object_property_add_alias(OBJECT(dev), "irq[0]", OBJECT(ms),
--
hw/ppc/spapr_drc.c=511=static void realize(DeviceState *d, Error **errp)
hw/ppc/spapr_drc.c:530:    object_property_add_alias(root_container, link_name,
hw/riscv/sifive_e.c=186=static void sifive_e_soc_realize(DeviceState *dev, Error **errp)
hw/riscv/sifive_e.c:233:    qdev_pass_gpios(DEVICE(&s->gpio), dev, NULL);
hw/riscv/sifive_u.c=651=static void sifive_u_soc_realize(DeviceState *dev, Error **errp)
hw/riscv/sifive_u.c:743:    qdev_pass_gpios(DEVICE(&s->gpio), dev, NULL);

-- 
Eduardo

Re: Purpose of QOM properties registered at realize time?

[BALATON Zoltan via]

On Tue, 6 Oct 2020, Eduardo Habkost wrote:
> Hi,
>
> 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?
>
> 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);
> --
> hw/arm/allwinner-h3.c=232=static void allwinner_h3_realize(DeviceState *dev, Error **errp)
> hw/arm/allwinner-h3.c:359:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->mmc0),
> --
> hw/arm/armsse.c=429=static void armsse_realize(DeviceState *dev, Error **errp)
> hw/arm/armsse.c:1092:    qdev_pass_gpios(dev_secctl, dev, "mscexp_status");
> --
> 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);
> --
> hw/arm/bcm2835_peripherals.c=128=static void bcm2835_peripherals_realize(DeviceState *dev, Error **errp)
> hw/arm/bcm2835_peripherals.c:322:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->gpio), "sd-bus");
> --
> hw/arm/bcm2836.c=69=static void bcm2836_realize(DeviceState *dev, Error **errp)
> hw/arm/bcm2836.c:87:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->peripherals),
> hw/arm/msf2-soc.c=79=static void m2sxxx_soc_realize(DeviceState *dev_soc, Error **errp)
> hw/arm/msf2-soc.c:170:        object_property_add_alias(OBJECT(s), bus_name,
> --
> hw/arm/nrf51_soc.c=58=static void nrf51_soc_realize(DeviceState *dev_soc, Error **errp)
> hw/arm/nrf51_soc.c:138:    qdev_pass_gpios(DEVICE(&s->gpio), dev_soc, NULL);
> --
> hw/arm/xlnx-zynqmp.c=276=static void xlnx_zynqmp_realize(DeviceState *dev, Error **errp)
> hw/arm/xlnx-zynqmp.c:522:        object_property_add_alias(OBJECT(s), bus_name, sdhci, "sd-bus");
> --
> hw/misc/mac_via.c=1011=static void mac_via_realize(DeviceState *dev, Error **errp)
> hw/misc/mac_via.c:1028:    object_property_add_alias(OBJECT(dev), "irq[0]", OBJECT(ms),

Mark likely knows this one. I think he mentioned once that it may be used 
for storing reference to some object that needs to be accessed later but I 
could be wrong, haven't checked actual code only recalling from memory.

Regards,
BALATON Zoltan

> --
> hw/ppc/spapr_drc.c=511=static void realize(DeviceState *d, Error **errp)
> hw/ppc/spapr_drc.c:530:    object_property_add_alias(root_container, link_name,
> hw/riscv/sifive_e.c=186=static void sifive_e_soc_realize(DeviceState *dev, Error **errp)
> hw/riscv/sifive_e.c:233:    qdev_pass_gpios(DEVICE(&s->gpio), dev, NULL);
> hw/riscv/sifive_u.c=651=static void sifive_u_soc_realize(DeviceState *dev, Error **errp)
> hw/riscv/sifive_u.c:743:    qdev_pass_gpios(DEVICE(&s->gpio), dev, NULL);
>
>

Re: Purpose of QOM properties registered at realize time?

[BALATON Zoltan]

On Tue, 6 Oct 2020, Eduardo Habkost wrote:
> Hi,
>
> 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?
>
> 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);
> --
> hw/arm/allwinner-h3.c=232=static void allwinner_h3_realize(DeviceState *dev, Error **errp)
> hw/arm/allwinner-h3.c:359:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->mmc0),
> --
> hw/arm/armsse.c=429=static void armsse_realize(DeviceState *dev, Error **errp)
> hw/arm/armsse.c:1092:    qdev_pass_gpios(dev_secctl, dev, "mscexp_status");
> --
> 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);
> --
> hw/arm/bcm2835_peripherals.c=128=static void bcm2835_peripherals_realize(DeviceState *dev, Error **errp)
> hw/arm/bcm2835_peripherals.c:322:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->gpio), "sd-bus");
> --
> hw/arm/bcm2836.c=69=static void bcm2836_realize(DeviceState *dev, Error **errp)
> hw/arm/bcm2836.c:87:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->peripherals),
> hw/arm/msf2-soc.c=79=static void m2sxxx_soc_realize(DeviceState *dev_soc, Error **errp)
> hw/arm/msf2-soc.c:170:        object_property_add_alias(OBJECT(s), bus_name,
> --
> hw/arm/nrf51_soc.c=58=static void nrf51_soc_realize(DeviceState *dev_soc, Error **errp)
> hw/arm/nrf51_soc.c:138:    qdev_pass_gpios(DEVICE(&s->gpio), dev_soc, NULL);
> --
> hw/arm/xlnx-zynqmp.c=276=static void xlnx_zynqmp_realize(DeviceState *dev, Error **errp)
> hw/arm/xlnx-zynqmp.c:522:        object_property_add_alias(OBJECT(s), bus_name, sdhci, "sd-bus");
> --
> hw/misc/mac_via.c=1011=static void mac_via_realize(DeviceState *dev, Error **errp)
> hw/misc/mac_via.c:1028:    object_property_add_alias(OBJECT(dev), "irq[0]", OBJECT(ms),

Mark likely knows this one. I think he mentioned once that it may be used 
for storing reference to some object that needs to be accessed later but I 
could be wrong, haven't checked actual code only recalling from memory.

Regards,
BALATON Zoltan

> --
> hw/ppc/spapr_drc.c=511=static void realize(DeviceState *d, Error **errp)
> hw/ppc/spapr_drc.c:530:    object_property_add_alias(root_container, link_name,
> hw/riscv/sifive_e.c=186=static void sifive_e_soc_realize(DeviceState *dev, Error **errp)
> hw/riscv/sifive_e.c:233:    qdev_pass_gpios(DEVICE(&s->gpio), dev, NULL);
> hw/riscv/sifive_u.c=651=static void sifive_u_soc_realize(DeviceState *dev, Error **errp)
> hw/riscv/sifive_u.c:743:    qdev_pass_gpios(DEVICE(&s->gpio), dev, NULL);
>
>

Re: Purpose of QOM properties registered at realize time?

[Paolo Bonzini]

On 07/10/20 00:06, Eduardo Habkost wrote:
> Hi,
> 
> 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?

In the case of GPIOs, I think they will be used by other devices that
are added afterwards.

The remaining ones are:

> hw/arm/allwinner-h3.c=232=static void allwinner_h3_realize(DeviceState *dev, Error **errp)
> hw/arm/allwinner-h3.c:359:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->mmc0),
> --
> hw/arm/bcm2835_peripherals.c=128=static void bcm2835_peripherals_realize(DeviceState *dev, Error **errp)
> hw/arm/bcm2835_peripherals.c:322:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->gpio), "sd-bus");
> --
> hw/arm/bcm2836.c=69=static void bcm2836_realize(DeviceState *dev, Error **errp)
> hw/arm/bcm2836.c:87:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->peripherals),
> --
> hw/arm/xlnx-zynqmp.c=276=static void xlnx_zynqmp_realize(DeviceState *dev, Error **errp)
> hw/arm/xlnx-zynqmp.c:522:        object_property_add_alias(OBJECT(s), bus_name, sdhci, "sd-bus");

And this are probably usable with "bus=sd-bus" or something like that on
other devices, too.

Paolo

Re: Purpose of QOM properties registered at realize time?

[Paolo Bonzini]

On 07/10/20 00:06, Eduardo Habkost wrote:
> Hi,
> 
> 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?

In the case of GPIOs, I think they will be used by other devices that
are added afterwards.

The remaining ones are:

> hw/arm/allwinner-h3.c=232=static void allwinner_h3_realize(DeviceState *dev, Error **errp)
> hw/arm/allwinner-h3.c:359:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->mmc0),
> --
> hw/arm/bcm2835_peripherals.c=128=static void bcm2835_peripherals_realize(DeviceState *dev, Error **errp)
> hw/arm/bcm2835_peripherals.c:322:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->gpio), "sd-bus");
> --
> hw/arm/bcm2836.c=69=static void bcm2836_realize(DeviceState *dev, Error **errp)
> hw/arm/bcm2836.c:87:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->peripherals),
> --
> hw/arm/xlnx-zynqmp.c=276=static void xlnx_zynqmp_realize(DeviceState *dev, Error **errp)
> hw/arm/xlnx-zynqmp.c:522:        object_property_add_alias(OBJECT(s), bus_name, sdhci, "sd-bus");

And this are probably usable with "bus=sd-bus" or something like that on
other devices, too.

Paolo

Re: Purpose of QOM properties registered at realize time?

[Eduardo Habkost]

On Wed, Oct 07, 2020 at 02:04:23PM +0200, Paolo Bonzini wrote:
> On 07/10/20 00:06, Eduardo Habkost wrote:
> > Hi,
> > 
> > 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?
> 
> In the case of GPIOs, I think they will be used by other devices that
> are added afterwards.

Do you know how exactly are they used?  Is this always wrapped
behind a specific API for GPIOs, or the devices can look for the
properties directly?

I'm concerned by the possibility of having QOM properties as an
undocumented part of an internal API.


> 
> The remaining ones are:
> 
> > hw/arm/allwinner-h3.c=232=static void allwinner_h3_realize(DeviceState *dev, Error **errp)
> > hw/arm/allwinner-h3.c:359:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->mmc0),
> > --
> > hw/arm/bcm2835_peripherals.c=128=static void bcm2835_peripherals_realize(DeviceState *dev, Error **errp)
> > hw/arm/bcm2835_peripherals.c:322:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->gpio), "sd-bus");
> > --
> > hw/arm/bcm2836.c=69=static void bcm2836_realize(DeviceState *dev, Error **errp)
> > hw/arm/bcm2836.c:87:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->peripherals),
> > --
> > hw/arm/xlnx-zynqmp.c=276=static void xlnx_zynqmp_realize(DeviceState *dev, Error **errp)
> > hw/arm/xlnx-zynqmp.c:522:        object_property_add_alias(OBJECT(s), bus_name, sdhci, "sd-bus");
> 
> And this are probably usable with "bus=sd-bus" or something like that on
> other devices, too.
> 
> Paolo
> 

-- 
Eduardo

Re: Purpose of QOM properties registered at realize time?

[Eduardo Habkost]

On Wed, Oct 07, 2020 at 02:04:23PM +0200, Paolo Bonzini wrote:
> On 07/10/20 00:06, Eduardo Habkost wrote:
> > Hi,
> > 
> > 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?
> 
> In the case of GPIOs, I think they will be used by other devices that
> are added afterwards.

Do you know how exactly are they used?  Is this always wrapped
behind a specific API for GPIOs, or the devices can look for the
properties directly?

I'm concerned by the possibility of having QOM properties as an
undocumented part of an internal API.


> 
> The remaining ones are:
> 
> > hw/arm/allwinner-h3.c=232=static void allwinner_h3_realize(DeviceState *dev, Error **errp)
> > hw/arm/allwinner-h3.c:359:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->mmc0),
> > --
> > hw/arm/bcm2835_peripherals.c=128=static void bcm2835_peripherals_realize(DeviceState *dev, Error **errp)
> > hw/arm/bcm2835_peripherals.c:322:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->gpio), "sd-bus");
> > --
> > hw/arm/bcm2836.c=69=static void bcm2836_realize(DeviceState *dev, Error **errp)
> > hw/arm/bcm2836.c:87:    object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(&s->peripherals),
> > --
> > hw/arm/xlnx-zynqmp.c=276=static void xlnx_zynqmp_realize(DeviceState *dev, Error **errp)
> > hw/arm/xlnx-zynqmp.c:522:        object_property_add_alias(OBJECT(s), bus_name, sdhci, "sd-bus");
> 
> And this are probably usable with "bus=sd-bus" or something like that on
> other devices, too.
> 
> Paolo
> 

-- 
Eduardo

Re: Purpose of QOM properties registered at realize time?

[Paolo Bonzini]

On 07/10/20 15:02, Eduardo Habkost wrote:
> On Wed, Oct 07, 2020 at 02:04:23PM +0200, Paolo Bonzini wrote:
>> On 07/10/20 00:06, Eduardo Habkost wrote:
>>> Hi,
>>>
>>> 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?
>>
>> In the case of GPIOs, I think they will be used by other devices that
>> are added afterwards.
> 
> Do you know how exactly are they used?  Is this always wrapped
> behind a specific API for GPIOs, or the devices can look for the
> properties directly?

It is always wrapped, but (as far as I recall, because I have never
worked with GPIOs) they are intentionally QOM properties and not just as
an implementation detail.  It's meant to be accessible to the user if
only through qom-get/qom-set.

Paolo

> I'm concerned by the possibility of having QOM properties as an
> undocumented part of an internal API.

Re: Purpose of QOM properties registered at realize time?

[Paolo Bonzini]

On 07/10/20 15:02, Eduardo Habkost wrote:
> On Wed, Oct 07, 2020 at 02:04:23PM +0200, Paolo Bonzini wrote:
>> On 07/10/20 00:06, Eduardo Habkost wrote:
>>> Hi,
>>>
>>> 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?
>>
>> In the case of GPIOs, I think they will be used by other devices that
>> are added afterwards.
> 
> Do you know how exactly are they used?  Is this always wrapped
> behind a specific API for GPIOs, or the devices can look for the
> properties directly?

It is always wrapped, but (as far as I recall, because I have never
worked with GPIOs) they are intentionally QOM properties and not just as
an implementation detail.  It's meant to be accessible to the user if
only through qom-get/qom-set.

Paolo

> I'm concerned by the possibility of having QOM properties as an
> undocumented part of an internal API.

Re: Purpose of QOM properties registered at realize time?

[Eduardo Habkost]

On Wed, Oct 07, 2020 at 03:55:58PM +0200, Paolo Bonzini wrote:
> On 07/10/20 15:02, Eduardo Habkost wrote:
> > On Wed, Oct 07, 2020 at 02:04:23PM +0200, Paolo Bonzini wrote:
> >> On 07/10/20 00:06, Eduardo Habkost wrote:
> >>> Hi,
> >>>
> >>> 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?
> >>
> >> In the case of GPIOs, I think they will be used by other devices that
> >> are added afterwards.
> > 
> > Do you know how exactly are they used?  Is this always wrapped
> > behind a specific API for GPIOs, or the devices can look for the
> > properties directly?
> 
> It is always wrapped, but (as far as I recall, because I have never
> worked with GPIOs) they are intentionally QOM properties and not just as
> an implementation detail.  It's meant to be accessible to the user if
> only through qom-get/qom-set.

Being accessible for debugging would be OK.  I'm just worried
about dynamic QOM properties being part of a stable and supported
API.

> 
> Paolo
> 
> > I'm concerned by the possibility of having QOM properties as an
> > undocumented part of an internal API.
> 

-- 
Eduardo

Re: Purpose of QOM properties registered at realize time?

[Eduardo Habkost]

On Wed, Oct 07, 2020 at 03:55:58PM +0200, Paolo Bonzini wrote:
> On 07/10/20 15:02, Eduardo Habkost wrote:
> > On Wed, Oct 07, 2020 at 02:04:23PM +0200, Paolo Bonzini wrote:
> >> On 07/10/20 00:06, Eduardo Habkost wrote:
> >>> Hi,
> >>>
> >>> 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?
> >>
> >> In the case of GPIOs, I think they will be used by other devices that
> >> are added afterwards.
> > 
> > Do you know how exactly are they used?  Is this always wrapped
> > behind a specific API for GPIOs, or the devices can look for the
> > properties directly?
> 
> It is always wrapped, but (as far as I recall, because I have never
> worked with GPIOs) they are intentionally QOM properties and not just as
> an implementation detail.  It's meant to be accessible to the user if
> only through qom-get/qom-set.

Being accessible for debugging would be OK.  I'm just worried
about dynamic QOM properties being part of a stable and supported
API.

> 
> Paolo
> 
> > I'm concerned by the possibility of having QOM properties as an
> > undocumented part of an internal API.
> 

-- 
Eduardo

Re: Purpose of QOM properties registered at realize time?

[Peter Maydell]

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

Re: Purpose of QOM properties registered at realize time?

[Peter Maydell]

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

Re: Purpose of QOM properties registered at realize time?

[Paolo Bonzini]

On 07/10/20 16:27, Eduardo Habkost wrote:
>> It is always wrapped, but (as far as I recall, because I have never
>> worked with GPIOs) they are intentionally QOM properties and not just as
>> an implementation detail.  It's meant to be accessible to the user if
>> only through qom-get/qom-set.
>
> Being accessible for debugging would be OK.  I'm just worried
> about dynamic QOM properties being part of a stable and supported
> API.

Certainly accessing the properties is only for debugging.

However, I am not sure if the _existence_ of GPIOs as dynamic QOM
properties is part of the API; that is, whether the user has to specify
the names of these properties to create some devices.  I don't think
that wouldn't be a problem anyway, what do you think?

Paolo

Re: Purpose of QOM properties registered at realize time?

[Paolo Bonzini]

On 07/10/20 16:27, Eduardo Habkost wrote:
>> It is always wrapped, but (as far as I recall, because I have never
>> worked with GPIOs) they are intentionally QOM properties and not just as
>> an implementation detail.  It's meant to be accessible to the user if
>> only through qom-get/qom-set.
>
> Being accessible for debugging would be OK.  I'm just worried
> about dynamic QOM properties being part of a stable and supported
> API.

Certainly accessing the properties is only for debugging.

However, I am not sure if the _existence_ of GPIOs as dynamic QOM
properties is part of the API; that is, whether the user has to specify
the names of these properties to create some devices.  I don't think
that wouldn't be a problem anyway, what do you think?

Paolo

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

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

Re: Purpose of QOM properties registered at realize time?

[Eduardo Habkost]

On Wed, Oct 07, 2020 at 04:54:31PM +0200, Paolo Bonzini wrote:
> On 07/10/20 16:27, Eduardo Habkost wrote:
> >> It is always wrapped, but (as far as I recall, because I have never
> >> worked with GPIOs) they are intentionally QOM properties and not just as
> >> an implementation detail.  It's meant to be accessible to the user if
> >> only through qom-get/qom-set.
> >
> > Being accessible for debugging would be OK.  I'm just worried
> > about dynamic QOM properties being part of a stable and supported
> > API.
> 
> Certainly accessing the properties is only for debugging.
> 
> However, I am not sure if the _existence_ of GPIOs as dynamic QOM
> properties is part of the API; that is, whether the user has to specify
> the names of these properties to create some devices.  I don't think
> that wouldn't be a problem anyway, what do you think?

Right now, I only want to know if the QOM property is part of a
supported stable external interface.  For the properties
registered at realize time, the answer seems to be "no".

Later, I might want to locate internal users of those QOM
properties too, to be able to refactor the code if necessary.

-- 
Eduardo

Re: Purpose of QOM properties registered at realize time?

[Eduardo Habkost]

On Wed, Oct 07, 2020 at 04:54:31PM +0200, Paolo Bonzini wrote:
> On 07/10/20 16:27, Eduardo Habkost wrote:
> >> It is always wrapped, but (as far as I recall, because I have never
> >> worked with GPIOs) they are intentionally QOM properties and not just as
> >> an implementation detail.  It's meant to be accessible to the user if
> >> only through qom-get/qom-set.
> >
> > Being accessible for debugging would be OK.  I'm just worried
> > about dynamic QOM properties being part of a stable and supported
> > API.
> 
> Certainly accessing the properties is only for debugging.
> 
> However, I am not sure if the _existence_ of GPIOs as dynamic QOM
> properties is part of the API; that is, whether the user has to specify
> the names of these properties to create some devices.  I don't think
> that wouldn't be a problem anyway, what do you think?

Right now, I only want to know if the QOM property is part of a
supported stable external interface.  For the properties
registered at realize time, the answer seems to be "no".

Later, I might want to locate internal users of those QOM
properties too, to be able to refactor the code if necessary.

-- 
Eduardo

Re: Purpose of QOM properties registered at realize time?

[Peter Maydell]

On Wed, 7 Oct 2020 at 16:51, Eduardo Habkost <ehabkost@redhat.com> wrote:
> Right now, I only want to know if the QOM property is part of a
> supported stable external interface.  For the properties
> registered at realize time, the answer seems to be "no".

I don't think that's inherently the case. But most QOM
properties are not going to be part of an external
interface (and definitely those for devices which are
not user-creatable are not), so the chances are good
that any particular QOM property is not external.

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

GPIOs are wired up with the APIs documented in
hw/qdev-core.h: typically qdev_get_gpio_in() to get
an anonymous GPIO input, qdev_get_gpio_in_named()
for a named GPIO line, similarly qdev_connect_gpio_out()
and qdev_connect_gpio_out_named() for oubound GPIO lines.
Most GPIOs are anonymous because that's the older set
of APIs (and sometimes it's still the simplest). To find
which code is wiring up the GPIOs from a particular
device you're better off searching for the device name,
because different devices can use the same name for a
set of GPIO lines (and lots of devices have anonymous
GPIO lines).

The GPIOs exposed by qdev_pass_gpios() are no different
from those exposed when the device directly creates
its own GPIOs.

thanks
-- PMM

Re: Purpose of QOM properties registered at realize time?

[Peter Maydell]

On Wed, 7 Oct 2020 at 16:51, Eduardo Habkost <ehabkost@redhat.com> wrote:
> Right now, I only want to know if the QOM property is part of a
> supported stable external interface.  For the properties
> registered at realize time, the answer seems to be "no".

I don't think that's inherently the case. But most QOM
properties are not going to be part of an external
interface (and definitely those for devices which are
not user-creatable are not), so the chances are good
that any particular QOM property is not external.

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

GPIOs are wired up with the APIs documented in
hw/qdev-core.h: typically qdev_get_gpio_in() to get
an anonymous GPIO input, qdev_get_gpio_in_named()
for a named GPIO line, similarly qdev_connect_gpio_out()
and qdev_connect_gpio_out_named() for oubound GPIO lines.
Most GPIOs are anonymous because that's the older set
of APIs (and sometimes it's still the simplest). To find
which code is wiring up the GPIOs from a particular
device you're better off searching for the device name,
because different devices can use the same name for a
set of GPIO lines (and lots of devices have anonymous
GPIO lines).

The GPIOs exposed by qdev_pass_gpios() are no different
from those exposed when the device directly creates
its own GPIOs.

thanks
-- PMM

Re: Purpose of QOM properties registered at realize time?

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

[...]
> 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.

In real hardware, the number of GPIOs and such is fixed.

When modelling a family of related chips, a "number of GPIOs" property
is sometimes convenient.  The property value is not available at
instance_init time.

By delaying GPIO creation to realize, you can create the configured
number.  The GPIO's QOM property becomes dynamic.

To keep the QOM property static, we'd have to provide the maximum number
of properties, and then connect only the configured number to actual
GPIOs.  This arguably goes against the grain of QOMs dynamic design.  I
never liked that part of the design anyway; I strongly prefer data to
code, and static to dynamic.

For purely virtual hardware, the maximum number might be impractically
large, though.

A first class static array property, where the size of the array is part
of the value could perhaps cover this case.

Re: Purpose of QOM properties registered at realize time?

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

[...]
> 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.

In real hardware, the number of GPIOs and such is fixed.

When modelling a family of related chips, a "number of GPIOs" property
is sometimes convenient.  The property value is not available at
instance_init time.

By delaying GPIO creation to realize, you can create the configured
number.  The GPIO's QOM property becomes dynamic.

To keep the QOM property static, we'd have to provide the maximum number
of properties, and then connect only the configured number to actual
GPIOs.  This arguably goes against the grain of QOMs dynamic design.  I
never liked that part of the design anyway; I strongly prefer data to
code, and static to dynamic.

For purely virtual hardware, the maximum number might be impractically
large, though.

A first class static array property, where the size of the array is part
of the value could perhaps cover this case.

Re: Purpose of QOM properties registered at realize time?

[Peter Maydell]

On Thu, 8 Oct 2020 at 10:45, Markus Armbruster <armbru@redhat.com> wrote:
> In real hardware, the number of GPIOs and such is fixed.

That depends on your point of view. Often this kind of
parameter is configurable in the hardware also, as a
parameter to the RTL, so different boards/SoCs using the
same device may vary in how they choose to configure it.

thanks
-- PMM

Re: Purpose of QOM properties registered at realize time?

[Peter Maydell]

On Thu, 8 Oct 2020 at 10:45, Markus Armbruster <armbru@redhat.com> wrote:
> In real hardware, the number of GPIOs and such is fixed.

That depends on your point of view. Often this kind of
parameter is configurable in the hardware also, as a
parameter to the RTL, so different boards/SoCs using the
same device may vary in how they choose to configure it.

thanks
-- PMM

Re: Purpose of QOM properties registered at realize time?

[Eduardo Habkost]

On Thu, Oct 08, 2020 at 11:45:08AM +0200, Markus Armbruster wrote:
> A first class static array property, where the size of the array is part
> of the value could perhaps cover this case.

This is an interesting idea, I think we should explore that.

qdev_pass_gpios() would become unnecessary and could be replaced
by a single (static) alias property.

-- 
Eduardo

Re: Purpose of QOM properties registered at realize time?

[Eduardo Habkost]

On Thu, Oct 08, 2020 at 11:45:08AM +0200, Markus Armbruster wrote:
> A first class static array property, where the size of the array is part
> of the value could perhaps cover this case.

This is an interesting idea, I think we should explore that.

qdev_pass_gpios() would become unnecessary and could be replaced
by a single (static) alias property.

-- 
Eduardo

Re: Purpose of QOM properties registered at realize time?

[Peter Maydell]

On Thu, 8 Oct 2020 at 16:15, Eduardo Habkost <ehabkost@redhat.com> wrote:
>
> On Thu, Oct 08, 2020 at 11:45:08AM +0200, Markus Armbruster wrote:
> > A first class static array property, where the size of the array is part
> > of the value could perhaps cover this case.
>
> This is an interesting idea, I think we should explore that.
>
> qdev_pass_gpios() would become unnecessary and could be replaced
> by a single (static) alias property.

At least in the current implementation, aliasing properties
is not the only thing qdev_pass_gpios() does -- it also
updates the NamedGPIOList data structures. It might be
possible to reimplement it so that we really are just
aliasing properties, though.

thanks
-- PMM

Re: Purpose of QOM properties registered at realize time?

[Peter Maydell]

On Thu, 8 Oct 2020 at 16:15, Eduardo Habkost <ehabkost@redhat.com> wrote:
>
> On Thu, Oct 08, 2020 at 11:45:08AM +0200, Markus Armbruster wrote:
> > A first class static array property, where the size of the array is part
> > of the value could perhaps cover this case.
>
> This is an interesting idea, I think we should explore that.
>
> qdev_pass_gpios() would become unnecessary and could be replaced
> by a single (static) alias property.

At least in the current implementation, aliasing properties
is not the only thing qdev_pass_gpios() does -- it also
updates the NamedGPIOList data structures. It might be
possible to reimplement it so that we really are just
aliasing properties, though.

thanks
-- PMM

Re: Purpose of QOM properties registered at realize time?

[Mark Cave-Ayland]

On 06/10/2020 23:06, Eduardo Habkost wrote:

> Hi,
> 
> 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?
> 
> For reference, these are the cases I've found:

(cut)

> --
> hw/misc/mac_via.c=1011=static void mac_via_realize(DeviceState *dev, Error **errp)
> hw/misc/mac_via.c:1028:    object_property_add_alias(OBJECT(dev), "irq[0]", OBJECT(ms),

This one was me trying to work out how to wire up an IRQ from a child device embedded
within the macio device - I'll send a patch to remove it shortly.


ATB,

Mark.