When introspecting properties for devices, libvirt issues a sequence of QMP 'device-list-properties' commands, one for each device type we need info for. The result of this command tells us about all properties possible on that specific device, which is generally just fine.
Every now and then though, there are properties that are inherited from / defined by the parent class, usually props that are common to all devices attached to a given bus type. The current case in point is the "acpi-index" property that was added to the "PCI" bus type, that is a parent for any type that is a PCI dev. Generally when libvirt adds support for a property, it will enable it across all devices that can support the property. So we're enabling use of "acpi-index" across all PCI devices. The question thus becomes how should we probe for existence of the "acpi-index" property. The qemu-system-x86_64 emulator has somewhere around 150 user creatable PCI devices according to "-device help". The existance of a class hierarchy is explicitly not exposed in QMP because we consider that an internal impl detail, so we can't just query "acpi-index" on the "PCI" parent type. We certainly don't want to issue 'device-list-properties' over and over for all 147 devices. If we just pick one device type, say virtio-blk-pci, and query that for "acpi-index", then our code is fragile because anyone can make a QEMU build that compiles-out a specific device. This is fairly unlikely for virtio devices, but never say never. For PCI, i'm tending towards probing for the "acpi-index" property on both "pci-bridge" and "pcie-root-port", as it seems unlikely that both of those will be compiled out of QEMU while still retaining PCI support. I'm wondering if QEMU maintainers have a view on "best practice" to probe for device props that are common to specific bus types ? 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 :|
