On Mon, Nov 07, 2016 at 09:09:58AM +0100, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost@xxxxxxxxxx> writes:
>
> > On Fri, Nov 04, 2016 at 04:45:17PM +0100, Markus Armbruster wrote:
> >> Eduardo Habkost <ehabkost@xxxxxxxxxx> 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 <ehabkost@xxxxxxxxxx> 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.
Looks cumbersome, because I don't see a way to find all
supertypes of a given type without walking the whole tree
starting from "object" (is there one?). But it could be improved
a bit if we added a "implements" field to ObjectTypeInfo.
But, maybe we should take a step back: my original goal was to
let libvirt know which properties are supported by any CPU model
when using "-cpu". Maybe we should make QEMU do the QOM->option
translation and implement "-cpu" support in
query-command-line-options? We already do something similar with
"-machine".
>
> >> >> 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.
Sure. This series originated from a request by Jiri to let him
know which options are supported by "-cpu".
--
Eduardo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list