Re: [libvirt] [Qemu-devel] [PATCH v3 4/6] numa: introduce "numa-mem-supported" machine property
On Mon, 27 May 2019 20:38:57 +0200
Markus Armbruster <armbru(a)redhat.com> wrote:
Igor Mammedov <imammedo(a)redhat.com> writes:
> '-numa mem' option has a number of issues and mgmt often defaults
> to it. Unfortunately it's no possible to replace it with an alternative
> '-numa memdev' without breaking migration compatibility.
To be precise: -numa node,mem=... and -numa node,memdev=... Correct?
yep, I'll
try to use full syntax since so it would be clear to others.
>
What's possible
> though is to deprecate it, keeping option working with old machine types.
> Once deprecation period expires, QEMU will disable '-numa mem' option,
> usage on new machine types and when the last machine type that supported
> it is removed we would be able to remove '-numa mem' with associated code.
>
> In order to help mgmt to find out if being deprecated CLI option
> '-numa mem=SZ' is still supported by particular machine type, expose
> this information via "numa-mem-supported" machine property.
>
> Users can use "qom-list-properties" QMP command to list machine type
> properties including initial proprety values (when probing for supported
> machine types with '-machine none') or at runtime at preconfig time
> before numa mapping is configured and decide if they should used legacy
> '-numa mem' or alternative '-numa memdev' option.
This sentence is impenetrable, I'm afraid :)
If we only want to convey whether a machine type supports -numa
node,mem=..., then adding a flag to query-machines suffices. Since I'm
pretty sure you'd have figured that out yourself, I suspect I'm missing
I
didn't know about query-machines, hence implemented "qom-list-properties"
approach as was discussed at
https://www.mail-archive.com/qemu-devel@nongnu.org/msg601220.html
For the purpose of deprecating '-numa node,mem" query-machines is more than
enough. I'll drop 1-3 patches and respin series using query-machines.
something. Can you give me some examples of intended usage?
Perhaps there will in future use cases when introspecting 'defaults'
of objects will be needed, then we could look back into qom-list-properties
if there aren't a better alternative.