diff options
Diffstat (limited to 'qemu-deprecated.texi')
| -rw-r--r-- | qemu-deprecated.texi | 52 |
1 files changed, 52 insertions, 0 deletions
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 40c017b..c90b08d 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -88,6 +88,39 @@ 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. + +@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. + +@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) @@ -259,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. |