From cdf80365205ad2b05519049eaa9a71c7804bd240 Mon Sep 17 00:00:00 2001 From: Igor Mammedov Date: Thu, 30 May 2019 10:33:18 +0200 Subject: numa: deprecate 'mem' parameter of '-numa node' option The parameter allows to configure fake NUMA topology where guest VM simulates NUMA topology but not actually getting performance benefits from it. The same or better results could be achieved using 'memdev' parameter. Beside of unpredictable performance, '-numa node.mem' option has other issues when it's used with combination of -mem-path + + -mem-prealloc + memdev backends (pc-dimm), breaking binding of memdev backends since mem-path/mem-prealloc are global and affect the most of RAM allocations. It's possible to make memdevs and global -mem-path/mem-prealloc to play nicely together but that will just complicate already complicated code and add unobious ways it could break on 2 different memmory allocation pathes and their combinations. Instead of it, consolidate all guest RAM allocation over memdev which still allows to create fake NUMA configurations if desired and leaves one simplifyed code path to consider when it comes to guest RAM allocation. To achieve desired simplification deprecate 'mem' parameter as its ad-hoc partitioning of initial RAM MemoryRegion can't be translated to memdev based backend transparently to users and in compatible manner (migration wise). Later down the road that will allow to consolidate means of how guest RAM is allocated and would permit us to clean up quite a bit memory allocations and numa code, leaving only 'memdev' implementation in place. Signed-off-by: Igor Mammedov Message-Id: <1559205199-233510-3-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost --- qemu-deprecated.texi | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'qemu-deprecated.texi') diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 40c017b..ba52999 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -88,6 +88,22 @@ The @code{-realtime mlock=on|off} argument has been replaced by the The ``-virtfs_synth'' argument is now deprecated. Please use ``-fsdev synth'' and ``-device virtio-9p-...'' instead. +@subsection -numa node,mem=@var{size} (since 4.1) + +The parameter @option{mem} of @option{-numa node} is used to assign a part of +guest RAM to a NUMA node. But when using it, it's impossible to manage specified +RAM chunk on the host side (like bind it to a host node, setting bind policy, ...), +so guest end-ups with the fake NUMA configuration with suboptiomal performance. +However since 2014 there is an alternative way to assign RAM to a NUMA node +using parameter @option{memdev}, which does the same as @option{mem} and adds +means to actualy manage node RAM on the host side. Use parameter @option{memdev} +with @var{memory-backend-ram} backend as an replacement for parameter @option{mem} +to achieve the same fake NUMA effect or a properly configured +@var{memory-backend-file} backend to actually benefit from NUMA configuration. +In future new machine versions will not accept the option but it will still +work with old machine types. User can check QAPI schema to see if the legacy +option is supported by looking at MachineInfo::numa-mem-supported property. + @section QEMU Machine Protocol (QMP) commands @subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0) -- cgit v1.1 From 4bb4a2732e097cd20594bab9039fcba9fac0b31f Mon Sep 17 00:00:00 2001 From: Igor Mammedov Date: Thu, 30 May 2019 10:33:19 +0200 Subject: numa: deprecate implict memory distribution between nodes 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 for the initial RAM. Signed-off-by: Igor Mammedov Message-Id: <1559205199-233510-4-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost --- qemu-deprecated.texi | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'qemu-deprecated.texi') diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index ba52999..4a626f5 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -104,6 +104,14 @@ In future new machine versions will not accept the option but it will still work with old machine types. User can check QAPI schema to see if the legacy option is supported by looking at MachineInfo::numa-mem-supported property. +@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) -- cgit v1.1 From cb79224b7e4b3d981c4080e60f20557739681000 Mon Sep 17 00:00:00 2001 From: Igor Mammedov Date: Wed, 26 Jun 2019 03:42:28 -0400 Subject: deprecate -mem-path fallback to anonymous RAM MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fallback might affect guest or worse whole host performance or functionality if backing file were used to share guest RAM with another process. Patch deprecates fallback so that we could remove it in future and ensure that QEMU will provide expected behavior and fail if it can't use user provided backing file. Signed-off-by: Igor Mammedov Reviewed-by: Daniel P. Berrangé Reviewed-by: Markus Armbruster Message-Id: <20190626074228.11558-1-imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Eduardo Habkost --- qemu-deprecated.texi | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'qemu-deprecated.texi') diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 4a626f5..e6891c3 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -112,6 +112,15 @@ 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. +@subsection -mem-path fallback to RAM (since 4.1) +Currently if guest RAM allocation from file pointed by @option{mem-path} +fails, QEMU falls back to allocating from RAM, which might result +in unpredictable behavior since the backing file specified by the user +is ignored. In the future, users will be responsible for making sure +the backing storage specified with @option{-mem-path} can actually provide +the guest RAM configured with @option{-m} and QEMU will fail to start up if +RAM allocation is unsuccessful. + @section QEMU Machine Protocol (QMP) commands @subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0) -- cgit v1.1 From aa5b969287125d1924d74648b378d4abba544465 Mon Sep 17 00:00:00 2001 From: Eduardo Habkost Date: Thu, 27 Jun 2019 21:28:43 -0300 Subject: docs: Deprecate CPU model runnability guarantees MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document that CPU model runnability guarantees won't apply to unversioned CPU models anymore. Signed-off-by: Eduardo Habkost Message-Id: <20190628002844.24894-9-ehabkost@redhat.com> Reviewed-by: Daniel P. Berrangé Signed-off-by: Eduardo Habkost --- qemu-deprecated.texi | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'qemu-deprecated.texi') diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index e6891c3..c90b08d 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -292,3 +292,22 @@ subset of the image. In the future, QEMU will require Python 3 to be available at build time. Support for Python 2 in scripts shipped with QEMU is deprecated. + +@section Backwards compatibility + +@subsection Runnability guarantee of CPU models (since 4.1.0) + +Previous versions of QEMU never changed existing CPU models in +ways that introduced additional host software or hardware +requirements to the VM. This allowed management software to +safely change the machine type of an existing VM without +introducing new requirements ("runnability guarantee"). This +prevented CPU models from being updated to include CPU +vulnerability mitigations, leaving guests vulnerable in the +default configuration. + +The CPU model runnability guarantee won't apply anymore to +existing CPU models. Management software that needs runnability +guarantees must resolve the CPU model aliases using te +``alias-of'' field returned by the ``query-cpu-definitions'' QMP +command. -- cgit v1.1