On Thu, 19 Dec 2024 at 18:32, Pierrick Bouvier
<pierrick.bouvier@linaro.org> wrote:
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
---
docs/system/arm/virt.rst | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/docs/system/arm/virt.rst b/docs/system/arm/virt.rst
index d25275c27ce..9f1457cf9a2 100644
--- a/docs/system/arm/virt.rst
+++ b/docs/system/arm/virt.rst
@@ -17,9 +17,17 @@ to have the same behaviour as that of previous QEMU
releases, so
that VM migration will work between QEMU versions. For instance the
``virt-5.0`` machine type will behave like the ``virt`` machine from
the QEMU 5.0 release, and migration should work between ``virt-5.0``
-of the 5.0 release and ``virt-5.0`` of the 5.1 release. Migration
-is not guaranteed to work between different QEMU releases for
-the non-versioned ``virt`` machine type.
+of the 5.0 release and ``virt-5.0`` of the 5.1 release.
+
+When saving a VM using the ``virt`` model, the snapshot is automatically set to
+target the latest ``virt`` versioned model. When loading the VM with a more
+recent QEMU version, you'll need to set machine model to match the version of
+your snapshot. When loading it, QEMU will return an error with the expected
+``virt`` version you should set, so you don't need to record it.
I don't think we should be encouraging this -- our standard approach
is "use the versioned machine types if you want migration", not
"you can start with an unversioned type on the source end". So I've
dropped this paragraph.
+
+VM migration is not guaranteed when using ``-cpu max``, as features supported
+may change between QEMU versions. To ensure your VM can be migrated, it is
+recommended to use another cpu model instead.
This paragraph is good, though -- that 'max' doesn't work for migration
is important, and we should definitely document that.