On Thu, 30 May 2019 10:33:16 +0200 Igor Mammedov <imammedo@xxxxxxxxxx> 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@xxxxxxxxxx/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@xxxxxxxxxx/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@xxxxxxxxxx/msg617694.html > > CC: libvir-list@xxxxxxxxxx > CC: ehabkost@xxxxxxxxxx > CC: pbonzini@xxxxxxxxxx > CC: berrange@xxxxxxxxxx > CC: armbru@xxxxxxxxxx > > 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(-) > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
