| Message ID | 20241219183211.3493974-4-pierrick.bouvier@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | Change default pointer authentication algorithm on aarch64 to impdef | expand |
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. thanks -- PMM
On 1/10/25 08:30, Peter Maydell wrote: > 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. > That's fine for me, I don't have a strong opinion on this. I just had a (good) surprise when I saved a vm with virt machine, and realised it's versioned by default. It's good to know that when you export a virt machine, you are guaranteed it's bound to a specific version, so you can always load it with new QEMU versions. This is what I tried to express with 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. > Agree! > thanks > -- PMM
On 10/1/25 17:30, Peter Maydell wrote: > 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 >> +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. Ah yes, I've been there. 2 close-by comments: - 'max' is not restricted to the 'virt' ARM machine, but this document is about it, what about other ARM machines? - More generally, "max" CPU won't migrate easily (in different versions) on all target archs. Not sure where to document that; maybe a generic chapter that can be included in a board.rst template?
On 1/10/25 13:29, Philippe Mathieu-Daudé wrote: > On 10/1/25 17:30, Peter Maydell wrote: >> 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 > > >>> +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. > > Ah yes, I've been there. 2 close-by comments: > > - 'max' is not restricted to the 'virt' ARM machine, but this document > is about it, what about other ARM machines? > > - More generally, "max" CPU won't migrate easily (in different versions) > on all target archs. > > Not sure where to document that; maybe a generic chapter that can be > included in a board.rst template? It's a good point. Maybe somewhere in docs/devel/migration, where versioning is mentioned?
On 10/1/25 23:59, Pierrick Bouvier wrote: > On 1/10/25 13:29, Philippe Mathieu-Daudé wrote: >> On 10/1/25 17:30, Peter Maydell wrote: >>> 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 >> >> >>>> +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. >> >> Ah yes, I've been there. 2 close-by comments: >> >> - 'max' is not restricted to the 'virt' ARM machine, but this document >> is about it, what about other ARM machines? >> >> - More generally, "max" CPU won't migrate easily (in different versions) >> on all target archs. >> >> Not sure where to document that; maybe a generic chapter that can be >> included in a board.rst template? > > It's a good point. > Maybe somewhere in docs/devel/migration, where versioning is mentioned? Yep. docs/devel/migration/compatibility.rst sounds the best place.
On 10/01/2025 21.54, Pierrick Bouvier wrote: > On 1/10/25 08:30, Peter Maydell wrote: >> 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. >> > > That's fine for me, I don't have a strong opinion on this. > I just had a (good) surprise when I saved a vm with virt machine, and > realised it's versioned by default. It's good to know that when you export a > virt machine, you are guaranteed it's bound to a specific version, so you > can always load it with new QEMU versions. This is what I tried to express > with this paragraph. Technically, the "virt" machine is not a real machine, but an alias of the latest machine: $ ./qemu-system-aarch64 -M help | grep alias virt QEMU 10.0 ARM Virtual Machine (alias of virt-10.0) So maybe that could be mentioned here instead? Thomas
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. + +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. Supported devices """""""""""""""""
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> --- docs/system/arm/virt.rst | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)