9:36 a.m.
(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(a)redhat.com> 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.
For the CPU case, I will propose adding the base QOM CPU typename
in the query-target command.
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.
> Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com>
> ---
> Changes series v1 -> v2:
> * (none)
>
> Changes series v2 -> v3:
> * Reworded commit message
>
> Changes series v3 -> v4:
> * (none)
> ---
> qmp.c | 21 +++++++++------------
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/qmp.c b/qmp.c
> index a06cb7b..1e7e60d 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -518,7 +518,7 @@ DevicePropertyInfoList *qmp_device_list_properties(const char
*typename,
> Error **errp)
> {
> ObjectClass *klass;
> - Object *obj;
> + Object *obj = NULL;
> ObjectProperty *prop;
> ObjectPropertyIterator iter;
> DevicePropertyInfoList *prop_list = NULL;
> @@ -537,19 +537,16 @@ DevicePropertyInfoList *qmp_device_list_properties(const char
*typename,
> }
>
> if (object_class_is_abstract(klass)) {
> - error_setg(errp, QERR_INVALID_PARAMETER_VALUE, "name",
> - "non-abstract device type");
> - return NULL;
> - }
> -
> - if (DEVICE_CLASS(klass)->cannot_destroy_with_object_finalize_yet) {
> - error_setg(errp, "Can't list properties of device
'%s'", typename);
> - return NULL;
> + object_class_property_iter_init(&iter, klass);
> + } else {
> + if (DEVICE_CLASS(klass)->cannot_destroy_with_object_finalize_yet) {
> + error_setg(errp, "Can't list properties of device
'%s'", typename);
> + return NULL;
> + }
> + obj = object_new(typename);
> + object_property_iter_init(&iter, obj);
> }
>
> - obj = object_new(typename);
> -
> - object_property_iter_init(&iter, obj);
> while ((prop = object_property_iter_next(&iter))) {
> DevicePropertyInfo *info;
> DevicePropertyInfoList *entry;
--
Eduardo
10:45 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
Eduardo Habkost <ehabkost(a)redhat.com> 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(a)redhat.com> 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?
> 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.
11:04 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
On Fri, Nov 04, 2016 at 04:45:17PM +0100, Markus Armbruster wrote:
Eduardo Habkost <ehabkost(a)redhat.com> 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(a)redhat.com> 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.
>> 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.
--
Eduardo
2:09 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
Eduardo Habkost <ehabkost(a)redhat.com> writes:
On Fri, Nov 04, 2016 at 04:45:17PM +0100, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost(a)redhat.com> 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(a)redhat.com> 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.
6:38 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
On Mon, Nov 07, 2016 at 09:09:58AM +0100, Markus Armbruster wrote:
Eduardo Habkost <ehabkost(a)redhat.com> writes:
> On Fri, Nov 04, 2016 at 04:45:17PM +0100, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost(a)redhat.com> 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(a)redhat.com> 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
8:40 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
Eduardo Habkost <ehabkost(a)redhat.com> writes:
On Mon, Nov 07, 2016 at 09:09:58AM +0100, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost(a)redhat.com> writes:
>
> > On Fri, Nov 04, 2016 at 04:45:17PM +0100, Markus Armbruster wrote:
> >> Eduardo Habkost <ehabkost(a)redhat.com> 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(a)redhat.com> 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.
My point is: we can skip discussing whether we should expose the subtype
relation, because we already do.
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".
Why is that useful?
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".
query-command-line-options is flawed, and the less it's used, the
happier I am.
Real command line introspection would be nice, but getting it will
involve cleaning up the unholy mess our command line has become. Don't
hold your breath.
My preferred workaround is to find something equivalent to introspect
via QMP.
That said, if you come up with a patch that solves a real problem now, I
won't object to it just because it involves query-command-line-options.
[...]
11:11 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
On Mon, Nov 07, 2016 at 03:40:57PM +0100, Markus Armbruster wrote:
Eduardo Habkost <ehabkost(a)redhat.com> writes:
> On Mon, Nov 07, 2016 at 09:09:58AM +0100, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost(a)redhat.com> writes:
>>
>> > On Fri, Nov 04, 2016 at 04:45:17PM +0100, Markus Armbruster wrote:
>> >> Eduardo Habkost <ehabkost(a)redhat.com> 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(a)redhat.com> 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.
My point is: we can skip discussing whether we should expose the subtype
relation, because we already do.
Correct. My only problem is that it seems to add extra
assumptions to the code (e.g. that there's only one abstract CPU
type). But if libvirt is careful, it doesn't need to make any
assumptions: it can explore the type hierarchy and confirm that
the assumptions are correct.
> 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".
Why is that useful?
libvirt wants to know if the QEMU binary supports a given -cpu
option (normally CPU features that can be enabled/disabled using
"+foo"/"-foo").
> 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".
query-command-line-options is flawed, and the less it's used, the
happier I am.
No problem, let's just forget my suggestion. :)
Real command line introspection would be nice, but getting it will
involve cleaning up the unholy mess our command line has become. Don't
hold your breath.
My preferred workaround is to find something equivalent to introspect
via QMP.
Sounds good to me.
That said, if you come up with a patch that solves a real problem now, I
won't object to it just because it involves query-command-line-options.
I think I will keep the current approach. Changing
query-command-line-option would probably be more complex and
solve only the -cpu problem. Making QOM introspection better
looks simpler and will probably be useful for other use cases.
I am still tempted to try to make QOM->query-command-line-option
mapping easier and simpler, but it doesn't seem to be the answer
to the current problem.
--
Eduardo
1:29 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
Eduardo Habkost <ehabkost(a)redhat.com> writes:
On Mon, Nov 07, 2016 at 03:40:57PM +0100, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost(a)redhat.com> writes:
>
> > On Mon, Nov 07, 2016 at 09:09:58AM +0100, Markus Armbruster wrote:
> >> Eduardo Habkost <ehabkost(a)redhat.com> writes:
> >>
> >> > On Fri, Nov 04, 2016 at 04:45:17PM +0100, Markus Armbruster wrote:
> >> >> Eduardo Habkost <ehabkost(a)redhat.com> 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(a)redhat.com> 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.
>
> My point is: we can skip discussing whether we should expose the subtype
> relation, because we already do.
Correct. My only problem is that it seems to add extra
assumptions to the code (e.g. that there's only one abstract CPU
type). But if libvirt is careful, it doesn't need to make any
assumptions: it can explore the type hierarchy and confirm that
the assumptions are correct.
>
> > 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".
>
> Why is that useful?
libvirt wants to know if the QEMU binary supports a given -cpu
option (normally CPU features that can be enabled/disabled using
"+foo"/"-foo").
The obvious way to check whether a specific CPU supports it is to
introspect that CPU.
The obvious way to check whether all CPUs of interest support it
(assuming that is a productive question) is to introspect all CPUs of
interest. Works regardless of whether the option is inherited, which is
really an implementation detail.
> > 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".
>
> query-command-line-options is flawed, and the less it's used, the
> happier I am.
No problem, let's just forget my suggestion. :)
>
> Real command line introspection would be nice, but getting it will
> involve cleaning up the unholy mess our command line has become. Don't
> hold your breath.
>
> My preferred workaround is to find something equivalent to introspect
> via QMP.
Sounds good to me.
>
> That said, if you come up with a patch that solves a real problem now, I
> won't object to it just because it involves query-command-line-options.
I think I will keep the current approach. Changing
query-command-line-option would probably be more complex and
solve only the -cpu problem. Making QOM introspection better
looks simpler and will probably be useful for other use cases.
Makes sense.
I am still tempted to try to make QOM->query-command-line-option
mapping easier and simpler, but it doesn't seem to be the answer
to the current problem.
6:17 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
On Tue, Nov 08, 2016 at 08:29:41 +0100, Markus Armbruster wrote:
Eduardo Habkost <ehabkost(a)redhat.com> writes:
> libvirt wants to know if the QEMU binary supports a given -cpu
> option (normally CPU features that can be enabled/disabled using
> "+foo"/"-foo").
The obvious way to check whether a specific CPU supports it is to
introspect that CPU.
The obvious way to check whether all CPUs of interest support it
(assuming that is a productive question) is to introspect all CPUs of
interest. Works regardless of whether the option is inherited, which is
really an implementation detail.
As Eduardo said, libvirt wants to know whether it can use a given CPU
feature with current QEMU binary. In -cpu help, we can see a list of
models and features QEMU understands, but we need to get similar info
via QMP. CPU models are easy, but how do we get the list of CPU
features? If introspection is the way to get it, I'm fine with that,
just beware that we don't actually know the name of the CPU object
(Westmere-x86_64-cpu), we only know the name of the CPU model
(Westmere). So if the object name is needed, we need to query the
mapping from CPU model names to CPU object names.
Jirka
6:34 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
On Fri, Nov 11, 2016 at 01:17:44PM +0100, Jiri Denemark wrote:
On Tue, Nov 08, 2016 at 08:29:41 +0100, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost(a)redhat.com> writes:
> > libvirt wants to know if the QEMU binary supports a given -cpu
> > option (normally CPU features that can be enabled/disabled using
> > "+foo"/"-foo").
>
> The obvious way to check whether a specific CPU supports it is to
> introspect that CPU.
>
> The obvious way to check whether all CPUs of interest support it
> (assuming that is a productive question) is to introspect all CPUs of
> interest. Works regardless of whether the option is inherited, which is
> really an implementation detail.
As Eduardo said, libvirt wants to know whether it can use a given CPU
feature with current QEMU binary. In -cpu help, we can see a list of
models and features QEMU understands, but we need to get similar info
via QMP. CPU models are easy, but how do we get the list of CPU
features? If introspection is the way to get it, I'm fine with that,
just beware that we don't actually know the name of the CPU object
(Westmere-x86_64-cpu), we only know the name of the CPU model
(Westmere). So if the object name is needed, we need to query the
mapping from CPU model names to CPU object names.
I have patches to add the QOM type name to query-cpu-definitions.
I don't remember if I submitted them to qemu-devel already. I
will check.
--
Eduardo
8:29 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
Jiri Denemark <jdenemar(a)redhat.com> writes:
On Tue, Nov 08, 2016 at 08:29:41 +0100, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost(a)redhat.com> writes:
> > libvirt wants to know if the QEMU binary supports a given -cpu
> > option (normally CPU features that can be enabled/disabled using
> > "+foo"/"-foo").
>
> The obvious way to check whether a specific CPU supports it is to
> introspect that CPU.
>
> The obvious way to check whether all CPUs of interest support it
> (assuming that is a productive question) is to introspect all CPUs of
> interest. Works regardless of whether the option is inherited, which is
> really an implementation detail.
As Eduardo said, libvirt wants to know whether it can use a given CPU
feature with current QEMU binary. In -cpu help, we can see a list of
models and features QEMU understands, but we need to get similar info
via QMP. CPU models are easy, but how do we get the list of CPU
features? If introspection is the way to get it, I'm fine with that,
just beware that we don't actually know the name of the CPU object
(Westmere-x86_64-cpu), we only know the name of the CPU model
(Westmere).
Actually, you do:
{ "execute": "qom-list-types", "arguments": {
"implements": "cpu" } }
{"return": [{"name": "Westmere-x86_64-cpu"}, ...]}
So if the object name is needed, we need to query the
mapping from CPU model names to CPU object names.
Hmm. The problem is that some interfaces such as -cpu require a "CPU
model name", but introspection gives you the QOM type name. The mapping
from "model name" to type name even depends on the target: it's CPUClass
method class_by_name().
Can't say I like that, but we got to play the hand we were dealt, and
that means we need to provide a way to introspect the mapping between
CPU model name and QOM type name. Eduardo's plan to add the QOM type
name to query-cpu-definitions makes more sense to me now.
2760
days inactive
2771
days old
10 comments
3 participants
participants (3)
-
Eduardo Habkost -
Jiri Denemark -
Markus Armbruster