Re: [Qemu-devel] [libvirt] [PATCH 1/2] numa: deprecate 'mem' parameter of '-numa node' option

[Igor Mammedov <imammedo@redhat.com>]

On Mon, 4 Mar 2019 15:28:11 +0000
Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Mon, Mar 04, 2019 at 12:45:14PM +0100, Markus Armbruster wrote:
> > Daniel P. Berrangé <berrange@redhat.com> 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