Re: [libvirt] [Qemu-devel] [PATCH 1/2] numa: deprecate 'mem' parameter of '-numa node' option
Daniel P. Berrangé <berrange(a)redhat.com> writes:
On Mon, Mar 04, 2019 at 12:45:14PM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange(a)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.
Yes.
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.
If it's an abstract type, qom-list-properties returns the properties
created with object_class_property_add() & friends, typically by the
class_init method. This is possible without instantiating the type.
If it's a concrete type, qom-list-properties additionally returns the
properties created with object_property_add(), typically by the
instance_init() method. This requires instantiating the type.
Both kinds of properties can be added or deleted at any time. For
instance, setting a property value with object_property_set() or similar
could create additional properties.
For historical reasons, we use often use object_property_add() where
object_class_property_add() would do. Sad.
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.
instance_init() also initializes the properties' values.
qom-list-properties could show these initial values (I hesitate calling
them default values).
Setting a property's value can change other properties' values by side
effect.
My point is: the properties qom-list-properties shows and the initial
values it could show are not necessarily final. QOM is designed to be
maximally flexible, and flexibility brings along its bosom-buddy
complexity.
If you keep that in mind, qom-list-properties can be put to good use all
the same.
A way to report "default values" (really: whatever the values are after
object_new()) feels like a fair feature request to me, if backed by an
actual use case.
[...]