On Tue, Oct 28, 2025 at 11:33:31AM +0100, Markus Armbruster wrote:
> Paolo Bonzini <[email protected]> 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 :|
