On Mon, 4 Mar 2019 15:28:11 +0000
Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
> On Mon, Mar 04, 2019 at 12:45:14PM +0100, Markus Armbruster wrote:
> > Daniel P. Berrangé <berrange@xxxxxxxxxx> writes:
> >
> > > On Mon, Mar 04, 2019 at 08:13:53AM +0100, Markus Armbruster wrote:
> > >> If we deprecate outdated NUMA configurations now, we can start rejecting
> > >> them with new machine types after a suitable grace period.
> > >
> > > How is libvirt going to know what machines it can use with the feature ?
> > > We don't have any way to introspect machine type specific logic, since we
> > > run all probing with "-machine none", and QEMU can't report anything about
> > > machines without instantiating them.
> >
> > Fair point. A practical way for management applications to decide which
> > of the two interfaces they can use with which machine type may be
> > required for deprecating one of the interfaces with new machine types.
>
> We currently have "qom-list-properties" which can report on the
> existance of properties registered against object types. What it
> can't do though is report on the default values of these properties.
>
> What's interesting though is that qmp_qom_list_properties will actually
> instantiate objects in order to query properties, if the type isn't an
> abstract type.
>
> IOW, even if you are running "$QEMU -machine none", then if at the qmp-shell
> you do
>
> (QEMU) qom-list-properties typename=pc-q35-2.6-machine
>
> it will have actually instantiate the pc-q35-2.6-machine machine type.
> Since it has instantiated the machine, the object initializer function
> will have run and initialized the default values for various properties.
>
> IOW, it is possible for qom-list-properties to report on default values
> for non-abstract types.
>
> I did a quick hack to PoC the theory:
>
> diff --git a/qapi/misc.json b/qapi/misc.json
> index 8b3ca4fdd3..906dfbf3b5 100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -1368,7 +1368,8 @@
> # Since: 1.2
> ##
> { 'struct': 'ObjectPropertyInfo',
> - 'data': { 'name': 'str', 'type': 'str', '*description': 'str' } }
> + 'data': { 'name': 'str', 'type': 'str', '*description': 'str',
> + '*default': 'str'} }
>
> ##
> # @qom-list:
> diff --git a/qmp.c b/qmp.c
> index b92d62cd5f..a45669032c 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -594,6 +594,11 @@ ObjectPropertyInfoList *qmp_qom_list_properties(const char *typename,
> info->has_description = !!prop->description;
> info->description = g_strdup(prop->description);
>
> + if (obj && g_str_equal(info->type, "string")) {
> + info->q_default = g_strdup(object_property_get_str(obj, info->name, NULL));
> + info->has_q_default = info->q_default != NULL;
> + }
> +
> entry = g_malloc0(sizeof(*entry));
> entry->value = info;
> entry->next = prop_list;
>
>
> If we could make this hack less of a hack, then perhaps this is good
> enough to cope reporting machine types which forbid use of "mem" in
> favour of "memdev" ? They would need to have a property registered
> against them of course to identify the "memdev" requirement.
Thanks, I'll look into it and try to come up with patches.
> Regards,
> Daniel
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
