qdev_print_props() retrieves a property's value from its legacy
property if it exists. A legacy property is created by
qdev_class_add_legacy_property() when the property has a print()
method or does not have a get() method.
If it has a print() method, the legacy property's value is obtained
from the property's print() method. This is used to format PCI
addresses nicely, i.e. like 01.3 instead of 11.
Else, if doesn't have a get() method, the legacy property is
unreadable. "info qtree" silently skips unreadable properties.
Link properties don't have a get() method, and are therefore skipped.
This is wrong, because the underlying QOM property *is* readable.
Change qdev_print_props() to simply use a print() method directly if
it exists, else get the value via QOM.
"info qtree" now shows links fine. For instance, machine "pc" onboard
device "PIIX4_PM" property "bus" is now visible.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
system/qdev-monitor.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index 2ac92d0a07..850f0c6606 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -745,19 +745,18 @@ static void qdev_print_props(Monitor *mon, DeviceState *dev, DeviceClass *dc,
for (int i = 0, n = dc->props_count_; i < n; ++i) {
const Property *prop = &dc->props_[i];
char *value;
- char *legacy_name = g_strdup_printf("legacy-%s", prop->name);
- if (object_property_get_type(OBJECT(dev), legacy_name, NULL)) {
- value = object_property_get_str(OBJECT(dev), legacy_name, NULL);
+ if (prop->info->print) {
+ value = prop->info->print(OBJECT(dev), prop);
} else {
value = object_property_print(OBJECT(dev), prop->name, true,
NULL);
}
- g_free(legacy_name);
if (!value) {
continue;
}
+
qdev_printf("%s = %s\n", prop->name,
*value ? value : "<null>");
g_free(value);
--
2.49.0On 10/22/25 12:14, Markus Armbruster wrote:
> qdev_print_props() retrieves a property's value from its legacy
> property if it exists. A legacy property is created by
> qdev_class_add_legacy_property() when the property has a print()
> method or does not have a get() method.
>
> If it has a print() method, the legacy property's value is obtained
> from the property's print() method. This is used to format PCI
> addresses nicely, i.e. like 01.3 instead of 11.
>
> Else, if doesn't have a get() method, the legacy property is
> unreadable. "info qtree" silently skips unreadable properties.
>
> Link properties don't have a get() method, and are therefore skipped.
> This is wrong, because the underlying QOM property *is* readable.
>
> Change qdev_print_props() to simply use a print() method directly if
> it exists, else get the value via QOM.
>
> "info qtree" now shows links fine. For instance, machine "pc" onboard
> device "PIIX4_PM" property "bus" is now visible.
It's been many years, but I think the original idea was that dc->props_
would be replaced with walking QOM properties.
I'm not opposed to the patch, but it would put the plan in the coffin so
I thought I'd point that out.
In the meanwhile I queued patch 1, which is an obviously good idea.
Paolo
>
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
> system/qdev-monitor.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
> index 2ac92d0a07..850f0c6606 100644
> --- a/system/qdev-monitor.c
> +++ b/system/qdev-monitor.c
> @@ -745,19 +745,18 @@ static void qdev_print_props(Monitor *mon, DeviceState *dev, DeviceClass *dc,
> for (int i = 0, n = dc->props_count_; i < n; ++i) {
> const Property *prop = &dc->props_[i];
> char *value;
> - char *legacy_name = g_strdup_printf("legacy-%s", prop->name);
>
> - if (object_property_get_type(OBJECT(dev), legacy_name, NULL)) {
> - value = object_property_get_str(OBJECT(dev), legacy_name, NULL);
> + if (prop->info->print) {
> + value = prop->info->print(OBJECT(dev), prop);
> } else {
> value = object_property_print(OBJECT(dev), prop->name, true,
> NULL);
> }
> - g_free(legacy_name);
>
> if (!value) {
> continue;
> }
> +
> qdev_printf("%s = %s\n", prop->name,
> *value ? value : "<null>");
> g_free(value);
Paolo Bonzini <pbonzini@redhat.com> writes: > On 10/22/25 12:14, Markus Armbruster wrote: >> qdev_print_props() retrieves a property's value from its legacy >> property if it exists. A legacy property is created by >> qdev_class_add_legacy_property() when the property has a print() >> method or does not have a get() method. >> >> If it has a print() method, the legacy property's value is obtained >> from the property's print() method. This is used to format PCI >> addresses nicely, i.e. like 01.3 instead of 11. >> >> Else, if doesn't have a get() method, the legacy property is >> unreadable. "info qtree" silently skips unreadable properties. >> >> Link properties don't have a get() method, and are therefore skipped. >> This is wrong, because the underlying QOM property *is* readable. >> >> Change qdev_print_props() to simply use a print() method directly if >> it exists, else get the value via QOM. >> >> "info qtree" now shows links fine. For instance, machine "pc" onboard >> device "PIIX4_PM" property "bus" is now visible. > > It's been many years, but I think the original idea was that dc->props_ would be replaced with walking QOM properties. > > I'm not opposed to the patch, but it would put the plan in the coffin so I thought I'd point that out. I'd argue that legacy properties are a questionable hack to preserve a specific solution to a problem. The problem: PCI addresses are integers in C and in QOM. Makes sense. But "info qtree" has always displayed PCI addresses in the form DEV.FN, which also makes sense. The pre-QOM solution: qdev property method .get() returns the integer, .print() formats it for humans. "info qtree" used the latter. Aside: "format for humans" may well be more widely applicable, if we care. The current QOM solution: QOM has no concept "format for humans", it has only .get(). Instead of introducing the concept, we added "legacy properties" whose .get() method wraps around qdev's .print() instead of qdev's .get(). This created yet another accidental external interface. Fixable the same way as other accidentally exposed properties: add the means to restrict access to C. How legacy properties work and how they're used is less than clear. Evidence: I was rather confused, and had to dig through quite a bit of code to unconfuse myself. I guess that would also be fixable to a degree with comments. My proposed solution: bypass QOM, use qdev directly. Quite a bit simpler. No need for additional comments, I hope. Kills the accidental external interface. A possible future solution: add the concept to QOM. Then we could walk QOM properties instead of dc->props_. So, it's not quite the coffin, more like the freezer. > In the meanwhile I queued patch 1, which is an obviously good idea. Thanks!
Markus Armbruster <armbru@redhat.com> writes: > Paolo Bonzini <pbonzini@redhat.com> writes: > >> On 10/22/25 12:14, Markus Armbruster wrote: >>> qdev_print_props() retrieves a property's value from its legacy >>> property if it exists. A legacy property is created by >>> qdev_class_add_legacy_property() when the property has a print() >>> method or does not have a get() method. >>> >>> If it has a print() method, the legacy property's value is obtained >>> from the property's print() method. This is used to format PCI >>> addresses nicely, i.e. like 01.3 instead of 11. >>> >>> Else, if doesn't have a get() method, the legacy property is >>> unreadable. "info qtree" silently skips unreadable properties. >>> >>> Link properties don't have a get() method, and are therefore skipped. >>> This is wrong, because the underlying QOM property *is* readable. >>> >>> Change qdev_print_props() to simply use a print() method directly if >>> it exists, else get the value via QOM. >>> >>> "info qtree" now shows links fine. For instance, machine "pc" onboard >>> device "PIIX4_PM" property "bus" is now visible. >> >> It's been many years, but I think the original idea was that dc->props_ would be replaced with walking QOM properties. >> >> I'm not opposed to the patch, but it would put the plan in the coffin so I thought I'd point that out. [...] > My proposed solution: bypass QOM, use qdev directly. Quite a bit > simpler. No need for additional comments, I hope. Kills the accidental > external interface. > > A possible future solution: add the concept to QOM. Then we could walk > QOM properties instead of dc->props_. So, it's not quite the coffin, > more like the freezer. > >> In the meanwhile I queued patch 1, which is an obviously good idea. Paolo, are you okay with the freezer? [...]
On Tue, 28 Oct 2025 at 10:34, Markus Armbruster <armbru@redhat.com> wrote: > The problem: PCI addresses are integers in C and in QOM. Makes sense. > But "info qtree" has always displayed PCI addresses in the form DEV.FN, > which also makes sense. > > The pre-QOM solution: qdev property method .get() returns the integer, > .print() formats it for humans. "info qtree" used the latter. > > Aside: "format for humans" may well be more widely applicable, if we > care. Relatedly, there are various places where we define a "string" QOM property and then format that into an underlying enum (though it is also nice not to have the enum values / representation not be public facing ABI)... -- PMM
On Tue, Oct 28, 2025 at 12:04 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Tue, 28 Oct 2025 at 10:34, Markus Armbruster <armbru@redhat.com> wrote: > > The problem: PCI addresses are integers in C and in QOM. Makes sense. > > But "info qtree" has always displayed PCI addresses in the form DEV.FN, > > which also makes sense. > > > > The pre-QOM solution: qdev property method .get() returns the integer, > > .print() formats it for humans. "info qtree" used the latter. > > > > Aside: "format for humans" may well be more widely applicable, if we > > care. > > Relatedly, there are various places where we define a "string" QOM > property and then format that into an underlying enum That is intended, a QOM property type can be any QAPI type (in addition to link<class> and child<class>) and therefore it can be the name of an enum. The PCI address case was done like this (I imagine) to avoid exposing it as a string. Paolo
On Tue, Oct 28, 2025 at 11:33:31AM +0100, Markus Armbruster wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
>
> > On 10/22/25 12:14, Markus Armbruster wrote:
> >> qdev_print_props() retrieves a property's value from its legacy
> >> property if it exists. A legacy property is created by
> >> qdev_class_add_legacy_property() when the property has a print()
> >> method or does not have a get() method.
> >>
> >> If it has a print() method, the legacy property's value is obtained
> >> from the property's print() method. This is used to format PCI
> >> addresses nicely, i.e. like 01.3 instead of 11.
> >>
> >> Else, if doesn't have a get() method, the legacy property is
> >> unreadable. "info qtree" silently skips unreadable properties.
> >>
> >> Link properties don't have a get() method, and are therefore skipped.
> >> This is wrong, because the underlying QOM property *is* readable.
> >>
> >> Change qdev_print_props() to simply use a print() method directly if
> >> it exists, else get the value via QOM.
> >>
> >> "info qtree" now shows links fine. For instance, machine "pc" onboard
> >> device "PIIX4_PM" property "bus" is now visible.
> >
> > It's been many years, but I think the original idea was that dc->props_ would be replaced with walking QOM properties.
> >
> > I'm not opposed to the patch, but it would put the plan in the coffin so I thought I'd point that out.
>
> I'd argue that legacy properties are a questionable hack to preserve a
> specific solution to a problem.
>
> The problem: PCI addresses are integers in C and in QOM. Makes sense.
> But "info qtree" has always displayed PCI addresses in the form DEV.FN,
> which also makes sense.
>
> The pre-QOM solution: qdev property method .get() returns the integer,
> .print() formats it for humans. "info qtree" used the latter.
>
> Aside: "format for humans" may well be more widely applicable, if we
> care.
The scope of the DEV.FN hack is worse than that - with PCI addresses,
while most of the time we just pass DEV, the QAPI also accepts it in
DEV.FN format for the 'addr' property and libvirt relies on that.
Here are two example CLIs that libvirt would generate when configuring
multi-function PCI placement:
For PCI-E (q35)
-device '{"driver":"pcie-root-port",
"port":19,
"chassis":16,
"id":"pci.16",
"bus":"pcie.0",
"multifunction":true,
"addr":"0x2.0x3"}'
For PCI (i440fx)
-device '{"driver":"lsi",
"id":"scsi2",
"bus":"pci.0",
"multifunction":true,
"addr":"0x4.0x1"}'
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Oct 28, 2025 at 11:59 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > On Tue, Oct 28, 2025 at 11:33:31AM +0100, Markus Armbruster wrote: > > Aside: "format for humans" may well be more widely applicable, if we > > care. > > The scope of the DEV.FN hack is worse than that - with PCI addresses, > while most of the time we just pass DEV, the QAPI also accepts it in > DEV.FN format for the 'addr' property and libvirt relies on that. That's fine, it's "just" a QAPI alternate type. A bit weird, but it works and is used by other QAPI side. The getter (printing) side is where the mess is. Paolo
On Wed, Oct 22, 2025 at 2:15 PM Markus Armbruster <armbru@redhat.com> wrote:
>
> qdev_print_props() retrieves a property's value from its legacy
> property if it exists. A legacy property is created by
> qdev_class_add_legacy_property() when the property has a print()
> method or does not have a get() method.
>
> If it has a print() method, the legacy property's value is obtained
> from the property's print() method. This is used to format PCI
> addresses nicely, i.e. like 01.3 instead of 11.
>
> Else, if doesn't have a get() method, the legacy property is
> unreadable. "info qtree" silently skips unreadable properties.
>
> Link properties don't have a get() method, and are therefore skipped.
> This is wrong, because the underlying QOM property *is* readable.
>
> Change qdev_print_props() to simply use a print() method directly if
> it exists, else get the value via QOM.
>
> "info qtree" now shows links fine. For instance, machine "pc" onboard
> device "PIIX4_PM" property "bus" is now visible.
>
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
> system/qdev-monitor.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
> index 2ac92d0a07..850f0c6606 100644
> --- a/system/qdev-monitor.c
> +++ b/system/qdev-monitor.c
> @@ -745,19 +745,18 @@ static void qdev_print_props(Monitor *mon, DeviceState *dev, DeviceClass *dc,
> for (int i = 0, n = dc->props_count_; i < n; ++i) {
> const Property *prop = &dc->props_[i];
> char *value;
> - char *legacy_name = g_strdup_printf("legacy-%s", prop->name);
>
> - if (object_property_get_type(OBJECT(dev), legacy_name, NULL)) {
> - value = object_property_get_str(OBJECT(dev), legacy_name, NULL);
> + if (prop->info->print) {
> + value = prop->info->print(OBJECT(dev), prop);
> } else {
> value = object_property_print(OBJECT(dev), prop->name, true,
> NULL);
> }
> - g_free(legacy_name);
>
> if (!value) {
> continue;
> }
> +
> qdev_printf("%s = %s\n", prop->name,
> *value ? value : "<null>");
> g_free(value);
> --
> 2.49.0
>
>
--
Marc-André Lureau
© 2016 - 2025 Red Hat, Inc.