@@ -409,6 +409,9 @@ void numa_complete_configuration(MachineState *ms)
if (i == nb_numa_nodes) {
assert(mc->numa_auto_assign_ram);
mc->numa_auto_assign_ram(mc, numa_info, nb_numa_nodes, ram_size);
+ warn_report("Default splitting of RAM between nodes is deprecated,"
+ " Use '-numa node,memdev' to explictly define RAM"
+ " allocation per node");
}
numa_total = 0;
@@ -88,6 +88,14 @@ In future new machine versions will not accept the option but it will keep
working with old machine types. User can inspect read-only machine property
'numa-mem-supported' to check if specific machine type (not) supports the option.
+@subsection -numa node (without memory specified) (since 4.1)
+
+Splitting RAM by default between NUMA nodes has the same issues as @option{mem}
+parameter described above with the difference that the role of the user plays
+QEMU using implicit generic or board specific splitting rule.
+Use @option{memdev} with @var{memory-backend-ram} backend or @option{mem} (if
+it's supported by used machine type) to define mapping explictly instead.
+
@section QEMU Machine Protocol (QMP) commands
@subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0)
Implicit RAM distribution between nodes has exactly the same issues as: "numa: deprecate 'mem' parameter of '-numa node' option" only with QEMU being the user that's 'adding' 'mem' parameter. Deprecate it, to get it out of the way so that we could consolidate guest RAM allocation using memory backends making it consistent and possibly later on transition to using memory devices instead of adhoc memory mapping of initial RAM. --- v3: - update deprecation doc, s/4.0/4.1/ - mention that legacy 'mem' option could also be used to provide explicit memory distribution for old machine types Signed-off-by: Igor Mammedov <imammedo@redhat.com> --- numa.c | 3 +++ qemu-deprecated.texi | 8 ++++++++ 2 files changed, 11 insertions(+)