qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: Igor Mammedov <imammedo@redhat.com>,
	Markus Armbruster <armbru@redhat.com>
Subject: QMP introspecting device props common to a bus type
Date: Wed, 7 Apr 2021 14:44:00 +0100	[thread overview]
Message-ID: <YG23ILea4H36TllU@redhat.com> (raw)

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 :|



             reply	other threads:[~2021-04-07 13:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-07 13:44 Daniel P. Berrangé [this message]
2021-04-08 11:56 ` Markus Armbruster
2021-04-08 12:46   ` Daniel P. Berrangé
2021-04-08 14:59     ` Markus Armbruster
2021-04-09  6:46       ` Gerd Hoffmann
2021-04-09  9:18         ` Markus Armbruster
2021-04-09  9:41           ` Daniel P. Berrangé
2021-04-09 14:04             ` Markus Armbruster

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=YG23ILea4H36TllU@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --subject='Re: QMP introspecting device props common to a bus type' \
    /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

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