Re: [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties

[Markus Armbruster]

Eduardo Habkost <address@hidden> writes:

> On Fri, Nov 04, 2016 at 04:45:17PM +0100, Markus Armbruster wrote:
>> Eduardo Habkost <address@hidden> writes:
>> 
>> > (CCing libvirt people, as I forgot to CC them)
>> >
>> > On Mon, Oct 31, 2016 at 03:07:23PM +0100, Igor Mammedov wrote:
>> >> On Fri, 28 Oct 2016 23:48:06 -0200
>> >> Eduardo Habkost <address@hidden> wrote:
>> >> 
>> >> > When an abstract class is used on device-list-properties, we can
>> >> > simply return the class properties registered for the class.
>> >> > 
>> >> > This will be useful if management software needs to query for
>> >> > supported options that apply to all devices of a given type (e.g.
>> >> > options supported by all CPU models, options supported by all PCI
>> >> > devices).
>> >> Patch looks fine to me but I'm not qmp interface guru
>> >> so I'd leave review up to maintainers.
>> >> 
>> >> One question though,
>> >> How would management software discover typename of abstract class?
>> >
>> > It depends on the use case. On some cases, management may already
>> > have bus-specific logic that will know what's the base type it
>> > needs to query (e.g. it may query "pci-device" to find out if all
>> > PCI devices support a given option). On other cases, it may be
>> > discovered using other commands.
>> 
>> The stated purpose of this feature is to let management software "query
>> for supported options that apply to all devices of a given type".  I
>> suspect that when management software has a notion of "a given type", it
>> knows its name.
>> 
>> Will management software go fishing for subtype relationships beyond the
>> types it knows?  I doubt it.  Of course, management software developers
>> are welcome to educate me :)
>> 
>> > For the CPU case, I will propose adding the base QOM CPU typename
>> > in the query-target command.
>> 
>> Does this type name vary?  If yes, can you give examples?
>
> It does. x86-specific CPU properties are on the x86_64-cpu and
> i386-cpu classes. arm-specific CPU properties are on the arm-cpu
> class.

I see we have concrete CPUs (such as "Westmere-x86_64-cpu"), which are
subtypes of an abstract CPU (such as "x86_64-cpu"), which is a subtype
of "cpu", which is a subtype of "device", which is a subtype of
"object".

The chain "cpu" - "device" - "object" is fixed and well-known.

The link from there to the concrete CPU varies.  Whether it could be
considered well-known or not is debatable.

My true question is: should we have a special purpose interface to get
the abstract supertype of concrete CPU types, or should be have general
purpose means to introspect the subtype hierarchy?

Note that we have the latter already, although in a rather cumbersome
form:

    { "execute": "qom-list-types",
      "arguments": { "implements": T, "abstract": true } }

lists all subtypes of T.  You can filter out the concrete subtypes by
subtracting the same query with "abstract": false.  Start with the
type you're interested in, find all its abstract supertypes.  If you
need to know more, repeat for the types you found.

>> >> Perhaps this patch should be part of some other series.
>> >
>> > This is a valid point. In this case, it depends on the approach
>> > we want to take: do we want to provide a flexible interface for
>> > management, let them find ways to make it useful and give us
>> > feedback on what is lacking; or do we want to provide the new
>> > interface only after we have specified the complete solution for
>> > the problem?
>> >
>> > I don't know the answer. I will let the qdev/QOM/QMP maintainers
>> > answer that.
>> 
>> I'm reluctant to add QMP features just because we think they might be
>> useful to someone.  We should talk to users to confirm our hunch before
>> we act on it.
>> 
>> That said, this one isn't exactly a biggie.
>
> Considering we are past soft freeze, I can document a more
> concrete usage example when I submit the next version.

I recommend you get libvirt developers to buy into this feature first.