From: Igor Mammedov <imammedo@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: libvir-list@redhat.com, pbonzini@redhat.com, berrange@redhat.com,
qemu-devel@nongnu.org, ehabkost@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 4/6] numa: introduce "numa-mem-supported" machine property
Date: Tue, 28 May 2019 15:14:37 +0200 [thread overview]
Message-ID: <20190528151437.5dab13d7@redhat.com> (raw)
In-Reply-To: <87woibhhdq.fsf@dusky.pond.sub.org>
On Mon, 27 May 2019 20:38:57 +0200
Markus Armbruster <armbru@redhat.com> wrote:
> Igor Mammedov <imammedo@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.
next prev parent reply other threads:[~2019-05-28 13:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-17 7:45 [Qemu-devel] [PATCH v3 0/6] numa: deprecate '-numa node, mem' and default memory distribution Igor Mammedov
2019-05-17 7:45 ` [Qemu-devel] [PATCH v3 1/6] pc: fix possible NULL pointer dereference in pc_machine_get_device_memory_region_size() Igor Mammedov
2019-05-27 16:36 ` Markus Armbruster
2019-05-28 13:46 ` Igor Mammedov
2019-05-17 7:45 ` [Qemu-devel] [PATCH v3 2/6] qmp: make "qom-list-properties" show initial property values Igor Mammedov
2019-05-27 18:15 ` Markus Armbruster
2019-05-17 7:45 ` [Qemu-devel] [PATCH v3 3/6] qmp: qmp_qom_list_properties(): ignore empty string options Igor Mammedov
2019-05-27 18:22 ` Markus Armbruster
2019-05-17 7:45 ` [Qemu-devel] [PATCH v3 4/6] numa: introduce "numa-mem-supported" machine property Igor Mammedov
2019-05-27 18:38 ` Markus Armbruster
2019-05-28 13:14 ` Igor Mammedov [this message]
2019-05-27 18:52 ` Eduardo Habkost
2019-05-17 7:45 ` [Qemu-devel] [PATCH v3 5/6] numa: deprecate 'mem' parameter of '-numa node' option Igor Mammedov
2019-05-17 7:45 ` [Qemu-devel] [PATCH v3 6/6] numa: deprecate implict memory distribution between nodes Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190528151437.5dab13d7@redhat.com \
--to=imammedo@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=libvir-list@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).