include/hw/boards.h | 3 +++ hw/arm/virt.c | 1 + hw/i386/pc.c | 1 + hw/ppc/spapr.c | 1 + numa.c | 5 +++++ qapi/misc.json | 5 ++++- qemu-deprecated.texi | 24 ++++++++++++++++++++++++ vl.c | 1 + 8 files changed, 40 insertions(+), 1 deletion(-)
Changes since v3:
- simplify series by dropping idea of showing property values in "qom-list-properties"
and use MachineInfo in QAPI schema instead
Changes since v2:
- taking in account previous review, implement a way for mgmt to intospect if
'-numa node,mem' is supported by machine type as suggested by Daniel at
https://www.mail-archive.com/qemu-devel@nongnu.org/msg601220.html
* ammend "qom-list-properties" to show property values
* add "numa-mem-supported" machine property to reflect if '-numa node,mem=SZ'
is supported. It culd be used with '-machine none' or at runtime with
--preconfig before numa memory mapping are configured
* minor fixes to deprecation documentation mentioning "numa-mem-supported" property
1) "I'm considering to deprecating -mem-path/prealloc CLI options and replacing
them with a single memdev Machine property to allow interested users to pick
used backend for initial RAM (fixes mixed -mem-path+hostmem backends issues)
and as a transition step to modeling initial RAM as a Device instead of
(ab)using MemoryRegion APIs."
(for more details see: https://www.mail-archive.com/qemu-devel@nongnu.org/msg596314.html)
However there is a couple of roadblocks on the way (s390x and numa memory handling).
I think I finally thought out a way to hack s390x in migration compatible manner,
but I don't see any way to do it for -numa node,mem and default RAM assignement
to nodes. Considering both numa usecases aren't meaningfully using NUMA (aside
guest side testing) and could be replaced with explicitly used memdev parameter,
I'd like to propose removing these fake NUMA friends on new machine types,
hence this deprecation. And once the last machie type that supported the option
is removed we would be able to remove option altogether.
As result of removing deprecated options and replacing initial RAM allocation
with 'memdev's (1), QEMU will allocate guest RAM in consistent way, fixing mixed
use-case and allowing boards to move towards modelling initial RAM as Device(s).
Which in its own turn should allow to cleanup NUMA/HMP/memory accounting code
more by dropping ad-hoc node_mem tracking and reusing memory device enumeration
instead.
Reference to previous versions:
* https://www.mail-archive.com/qemu-devel@nongnu.org/msg617694.html
CC: libvir-list@redhat.com
CC: ehabkost@redhat.com
CC: pbonzini@redhat.com
CC: berrange@redhat.com
CC: armbru@redhat.com
Igor Mammedov (3):
machine: show if CLI option '-numa node,mem' is supported in QAPI
schema
numa: deprecate 'mem' parameter of '-numa node' option
numa: deprecate implict memory distribution between nodes
include/hw/boards.h | 3 +++
hw/arm/virt.c | 1 +
hw/i386/pc.c | 1 +
hw/ppc/spapr.c | 1 +
numa.c | 5 +++++
qapi/misc.json | 5 ++++-
qemu-deprecated.texi | 24 ++++++++++++++++++++++++
vl.c | 1 +
8 files changed, 40 insertions(+), 1 deletion(-)
--
2.7.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Igor Mammedov <imammedo@redhat.com> writes: > Changes since v3: > - simplify series by dropping idea of showing property values in "qom-list-properties" > and use MachineInfo in QAPI schema instead Where did "[PATCH v3 1/6] pc: fix possible NULL pointer dereference in pc_machine_get_device_memory_region_size()" go? It fixes a crash bug... -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, 07 Jun 2019 19:28:58 +0200 Markus Armbruster <armbru@redhat.com> wrote: > Igor Mammedov <imammedo@redhat.com> writes: > > > Changes since v3: > > - simplify series by dropping idea of showing property values in "qom-list-properties" > > and use MachineInfo in QAPI schema instead > > Where did "[PATCH v3 1/6] pc: fix possible NULL pointer dereference in > pc_machine_get_device_memory_region_size()" go? It fixes a crash bug... I'll post it as separate patch as it's not more related to this series
On Thu, 30 May 2019 10:33:16 +0200 Igor Mammedov <imammedo@redhat.com> wrote: > Changes since v3: > - simplify series by dropping idea of showing property values in "qom-list-properties" > and use MachineInfo in QAPI schema instead > > Changes since v2: > - taking in account previous review, implement a way for mgmt to intospect if > '-numa node,mem' is supported by machine type as suggested by Daniel at > https://www.mail-archive.com/qemu-devel@nongnu.org/msg601220.html > * ammend "qom-list-properties" to show property values > * add "numa-mem-supported" machine property to reflect if '-numa node,mem=SZ' > is supported. It culd be used with '-machine none' or at runtime with > --preconfig before numa memory mapping are configured > * minor fixes to deprecation documentation mentioning "numa-mem-supported" property > > 1) "I'm considering to deprecating -mem-path/prealloc CLI options and replacing > them with a single memdev Machine property to allow interested users to pick > used backend for initial RAM (fixes mixed -mem-path+hostmem backends issues) > and as a transition step to modeling initial RAM as a Device instead of > (ab)using MemoryRegion APIs." > (for more details see: https://www.mail-archive.com/qemu-devel@nongnu.org/msg596314.html) > > However there is a couple of roadblocks on the way (s390x and numa memory handling). > I think I finally thought out a way to hack s390x in migration compatible manner, > but I don't see any way to do it for -numa node,mem and default RAM assignement > to nodes. Considering both numa usecases aren't meaningfully using NUMA (aside > guest side testing) and could be replaced with explicitly used memdev parameter, > I'd like to propose removing these fake NUMA friends on new machine types, > hence this deprecation. And once the last machie type that supported the option > is removed we would be able to remove option altogether. > > As result of removing deprecated options and replacing initial RAM allocation > with 'memdev's (1), QEMU will allocate guest RAM in consistent way, fixing mixed > use-case and allowing boards to move towards modelling initial RAM as Device(s). > Which in its own turn should allow to cleanup NUMA/HMP/memory accounting code > more by dropping ad-hoc node_mem tracking and reusing memory device enumeration > instead. Eduardo, could you take and merge it via numa/machine tree? > > Reference to previous versions: > * https://www.mail-archive.com/qemu-devel@nongnu.org/msg617694.html > > CC: libvir-list@redhat.com > CC: ehabkost@redhat.com > CC: pbonzini@redhat.com > CC: berrange@redhat.com > CC: armbru@redhat.com > > Igor Mammedov (3): > machine: show if CLI option '-numa node,mem' is supported in QAPI > schema > numa: deprecate 'mem' parameter of '-numa node' option > numa: deprecate implict memory distribution between nodes > > include/hw/boards.h | 3 +++ > hw/arm/virt.c | 1 + > hw/i386/pc.c | 1 + > hw/ppc/spapr.c | 1 + > numa.c | 5 +++++ > qapi/misc.json | 5 ++++- > qemu-deprecated.texi | 24 ++++++++++++++++++++++++ > vl.c | 1 + > 8 files changed, 40 insertions(+), 1 deletion(-) >
To summarize implications on libvirt... This patch currently doesn't change the deprecation status of any machine type, so it is effectively no-op metadata addition right now. Libvirt version N can implement support for this today, and nothing would change from a functional POV with QEMU 4.1. At some later time, a QEMU release X.Y will mark a new machine type has having this deprecation enabled, at which point the dormant libvirt logic will activate, causing libvirt to use the new syntax for NUMA. IOW, libvirt version N onwards can live migrate QEMU with machine type pc-X.Y to a host with arbitrary future libvirt or QEMU version. Libvirt version N-1 can *not* live migrate QEMU with machine type pc-X.Y to a host with libvirt version N or newer. This restriction won't be a problem in practice if there's a moderate time window between libvirt implementing support for this concept, and the future QEMU X.Y which actually enables the deprecation. The main downside of this approach is the one Eduardo raised previously which is that the dormant libvirt logic will not be testable/tested until that QEMU X.Y actually arrives. The testing gap is not nice, but I don't think it is sufficient to reject this approach entirely. I wonder if there's a way to close the testing gap somehow ? Random idea would be a non-versioned "pc-no-deprecated" machine type, which blocks all use of deprecated features and does not promise any migration compat. Essentially it would exist just for testing purposem as a way todo functional tests for libvirt & mgmt apps to prove they don't use any deprecated features (any deprecated features, not merely this NUMA one). On Thu, May 30, 2019 at 10:33:16AM +0200, Igor Mammedov wrote: > Changes since v3: > - simplify series by dropping idea of showing property values in "qom-list-properties" > and use MachineInfo in QAPI schema instead > > Changes since v2: > - taking in account previous review, implement a way for mgmt to intospect if > '-numa node,mem' is supported by machine type as suggested by Daniel at > https://www.mail-archive.com/qemu-devel@nongnu.org/msg601220.html > * ammend "qom-list-properties" to show property values > * add "numa-mem-supported" machine property to reflect if '-numa node,mem=SZ' > is supported. It culd be used with '-machine none' or at runtime with > --preconfig before numa memory mapping are configured > * minor fixes to deprecation documentation mentioning "numa-mem-supported" property > > 1) "I'm considering to deprecating -mem-path/prealloc CLI options and replacing > them with a single memdev Machine property to allow interested users to pick > used backend for initial RAM (fixes mixed -mem-path+hostmem backends issues) > and as a transition step to modeling initial RAM as a Device instead of > (ab)using MemoryRegion APIs." > (for more details see: https://www.mail-archive.com/qemu-devel@nongnu.org/msg596314.html) > > However there is a couple of roadblocks on the way (s390x and numa memory handling). > I think I finally thought out a way to hack s390x in migration compatible manner, > but I don't see any way to do it for -numa node,mem and default RAM assignement > to nodes. Considering both numa usecases aren't meaningfully using NUMA (aside > guest side testing) and could be replaced with explicitly used memdev parameter, > I'd like to propose removing these fake NUMA friends on new machine types, > hence this deprecation. And once the last machie type that supported the option > is removed we would be able to remove option altogether. > > As result of removing deprecated options and replacing initial RAM allocation > with 'memdev's (1), QEMU will allocate guest RAM in consistent way, fixing mixed > use-case and allowing boards to move towards modelling initial RAM as Device(s). > Which in its own turn should allow to cleanup NUMA/HMP/memory accounting code > more by dropping ad-hoc node_mem tracking and reusing memory device enumeration > instead. > > Reference to previous versions: > * https://www.mail-archive.com/qemu-devel@nongnu.org/msg617694.html > > CC: libvir-list@redhat.com > CC: ehabkost@redhat.com > CC: pbonzini@redhat.com > CC: berrange@redhat.com > CC: armbru@redhat.com > > Igor Mammedov (3): > machine: show if CLI option '-numa node,mem' is supported in QAPI > schema > numa: deprecate 'mem' parameter of '-numa node' option > numa: deprecate implict memory distribution between nodes > > include/hw/boards.h | 3 +++ > hw/arm/virt.c | 1 + > hw/i386/pc.c | 1 + > hw/ppc/spapr.c | 1 + > numa.c | 5 +++++ > qapi/misc.json | 5 ++++- > qemu-deprecated.texi | 24 ++++++++++++++++++++++++ > vl.c | 1 + > 8 files changed, 40 insertions(+), 1 deletion(-) > > -- > 2.7.4 > 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Jun 05, 2019 at 06:33:11PM +0100, Daniel P. Berrangé wrote: [...] > I wonder if there's a way to close the testing gap somehow ? Random idea > would be a non-versioned "pc-no-deprecated" machine type, which blocks > all use of deprecated features and does not promise any migration compat. > Essentially it would exist just for testing purposem as a way todo > functional tests for libvirt & mgmt apps to prove they don't use any > deprecated features (any deprecated features, not merely this NUMA one). This isn't the first time I wish we had a machine type with experimental features enabled. What about calling it "pc-next"? -- Eduardo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Jun 05, 2019 at 03:06:08PM -0300, Eduardo Habkost wrote: > On Wed, Jun 05, 2019 at 06:33:11PM +0100, Daniel P. Berrangé wrote: > [...] > > I wonder if there's a way to close the testing gap somehow ? Random idea > > would be a non-versioned "pc-no-deprecated" machine type, which blocks > > all use of deprecated features and does not promise any migration compat. > > Essentially it would exist just for testing purposem as a way todo > > functional tests for libvirt & mgmt apps to prove they don't use any > > deprecated features (any deprecated features, not merely this NUMA one). > > This isn't the first time I wish we had a machine type with > experimental features enabled. What about calling it "pc-next"? No objection from me. 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 :|
© 2016 - 2024 Red Hat, Inc.