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.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
