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

[Igor Mammedov]

On Sun, 10 Mar 2019 11:14:08 +0100
Markus Armbruster <armbru at redhat.com> wrote:

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

Looks like trying to migrate from 'mem' to 'memdev', just creates another
train-wreck (where libvirt would have to hunt for 'right' backend
configuration to make migration work and even that would be best effort
attempt). If that would work reliably, I'd go for it since it allows to
drop 'mem' codepath altogether but it doesn't look possible.
So I'll look into adding machine level introspection and deprecating 'mem'
option for new machine types.

> [...]
>