[v2] spapr: Tag pseries-2.1 - 2.11 machines as deprecated

pseries machines before version 2.11 have undergone many changes to
correct issues, mostly regarding migration compatibility. This is
obfuscating the code uselessly and makes maintenance more difficult.
Remove them and only keep the last version of the 2.x series, 2.12,
still in use by old distros.

Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 docs/about/deprecated.rst | 7 +++++++
 hw/ppc/spapr.c            | 1 +
 2 files changed, 8 insertions(+)

On 12/14/23 15:17, Cédric Le Goater wrote:
> pseries machines before version 2.11 have undergone many changes to
> correct issues, mostly regarding migration compatibility. This is
> obfuscating the code uselessly and makes maintenance more difficult.
> Remove them and only keep the last version of the 2.x series, 2.12,
> still in use by old distros.
> 
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---


Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>

>   docs/about/deprecated.rst | 7 +++++++
>   hw/ppc/spapr.c            | 1 +
>   2 files changed, 8 insertions(+)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 2e1504024658..c0e22b2b568f 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -269,6 +269,13 @@ Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2)
>   
>   The Nios II architecture is orphan.
>   
> +``pseries-2.1`` up to ``pseries-2.11`` (since 9.0)
> +''''''''''''''''''''''''''''''''''''''''''''''''''
> +
> +Older pseries machines before version 2.12 have undergone many changes
> +to correct issues, mostly regarding migration compatibility. These are
> +no longer maintained and removing them will make the code easier to
> +read and maintain. Use versions 2.12 and above as a replacement.
>   
>   Backend options
>   ---------------
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index df09aa9d6a00..5034461399d2 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -5083,6 +5083,7 @@ static void spapr_machine_2_11_class_options(MachineClass *mc)
>       spapr_machine_2_12_class_options(mc);
>       smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_ON;
>       compat_props_add(mc->compat_props, hw_compat_2_11, hw_compat_2_11_len);
> +    mc->deprecation_reason = "old and not maintained - use a 2.12+ version";
>   }
>   
>   DEFINE_SPAPR_MACHINE(2_11, "2.11", false);

Hi,

On 14/12/23 19:17, Cédric Le Goater wrote:
> pseries machines before version 2.11 have undergone many changes to
> correct issues, mostly regarding migration compatibility. This is
> obfuscating the code uselessly and makes maintenance more difficult.
> Remove them and only keep the last version of the 2.x series, 2.12,
> still in use by old distros.

By the time we get to QEMU v9.2, will pseries-2.12 still be used
by old distros? (which ones btw?)

What about also deprecating pseries-2.12 and pseries-2.12-sxxm
which both set pre_3_0_migration, and suggest to use pseries-3.0
instead?

> 
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
>   docs/about/deprecated.rst | 7 +++++++
>   hw/ppc/spapr.c            | 1 +
>   2 files changed, 8 insertions(+)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 2e1504024658..c0e22b2b568f 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -269,6 +269,13 @@ Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2)
>   
>   The Nios II architecture is orphan.
>   
> +``pseries-2.1`` up to ``pseries-2.11`` (since 9.0)
> +''''''''''''''''''''''''''''''''''''''''''''''''''
> +
> +Older pseries machines before version 2.12 have undergone many changes
> +to correct issues, mostly regarding migration compatibility. These are
> +no longer maintained and removing them will make the code easier to
> +read and maintain. Use versions 2.12 and above as a replacement.

On 3/11/24 18:46, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> On 14/12/23 19:17, Cédric Le Goater wrote:
>> pseries machines before version 2.11 have undergone many changes to
>> correct issues, mostly regarding migration compatibility. This is
>> obfuscating the code uselessly and makes maintenance more difficult.
>> Remove them and only keep the last version of the 2.x series, 2.12,
>> still in use by old distros.
> 
> By the time we get to QEMU v9.2, will pseries-2.12 still be used
> by old distros? (which ones btw?)

Using info from https://repology.org/api/v1/project/qemu :

alpine_3_8: 2.12.0
aur: 2.10.0, 2.7.1, 8.2.0.r1767.g91e3bf2e92
epel_7: 2.0.0
fedora_26: 2.9.0, 2.9.1
fedora_27: 2.10.0, 2.10.2
fedora_28: 2.11.1, 2.11.2
freshcode: 2.8.0
gnuguix: 2.10.2, 8.1.3
opensuse_leap_15_0: 2.11.1, 2.11.2, 3.1.1.1, 4.2.1, 5.2.0
opensuse_leap_42_3: 2.9.0, 2.9.1
openwrt_17_01_x86_64: 2.6.2
openwrt_18_06_x86_64: 2.11.1
rosa_2016_1: 2.10.1, 2.5.1.1
slackbuilds: 2.12.0, 7.2.1
slitaz_next: 2.0.2
ubuntu_14_04: 2.0.0, 2.0.0~rc1
ubuntu_16_04: 2.5
ubuntu_18_04: 2.11

Thanks to Thomas !

C.


> 
> What about also deprecating pseries-2.12 and pseries-2.12-sxxm
> which both set pre_3_0_migration, and suggest to use pseries-3.0
> instead?
> 
>>
>> Reviewed-by: Thomas Huth <thuth@redhat.com>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>>   docs/about/deprecated.rst | 7 +++++++
>>   hw/ppc/spapr.c            | 1 +
>>   2 files changed, 8 insertions(+)
>>
>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>> index 2e1504024658..c0e22b2b568f 100644
>> --- a/docs/about/deprecated.rst
>> +++ b/docs/about/deprecated.rst
>> @@ -269,6 +269,13 @@ Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2)
>>   The Nios II architecture is orphan.
>> +``pseries-2.1`` up to ``pseries-2.11`` (since 9.0)
>> +''''''''''''''''''''''''''''''''''''''''''''''''''
>> +
>> +Older pseries machines before version 2.12 have undergone many changes
>> +to correct issues, mostly regarding migration compatibility. These are
>> +no longer maintained and removing them will make the code easier to
>> +read and maintain. Use versions 2.12 and above as a replacement.
>

On Mon, Mar 11, 2024 at 06:46:53PM +0100, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> On 14/12/23 19:17, Cédric Le Goater wrote:
> > pseries machines before version 2.11 have undergone many changes to
> > correct issues, mostly regarding migration compatibility. This is
> > obfuscating the code uselessly and makes maintenance more difficult.
> > Remove them and only keep the last version of the 2.x series, 2.12,
> > still in use by old distros.
> 
> By the time we get to QEMU v9.2, will pseries-2.12 still be used
> by old distros? (which ones btw?)

That's the wrong question really.

Machine types are there to facilitate live migration, and by
extension also handle save/restore to disk.

So the question is more which distros are likely to ship
new QEMU 9.2, and also still need the ability to incoming
migrate from an older version of their distro where 2.12
(or a downstream equiv) was a fully supported machine type.

With regards,
Daniel

On Tue Mar 12, 2024 at 4:56 AM AEST, Daniel P. Berrangé wrote:
> On Mon, Mar 11, 2024 at 06:46:53PM +0100, Philippe Mathieu-Daudé wrote:
> > Hi,
> > 
> > On 14/12/23 19:17, Cédric Le Goater wrote:
> > > pseries machines before version 2.11 have undergone many changes to
> > > correct issues, mostly regarding migration compatibility. This is
> > > obfuscating the code uselessly and makes maintenance more difficult.
> > > Remove them and only keep the last version of the 2.x series, 2.12,
> > > still in use by old distros.
> > 
> > By the time we get to QEMU v9.2, will pseries-2.12 still be used
> > by old distros? (which ones btw?)
>
> That's the wrong question really.
>
> Machine types are there to facilitate live migration, and by
> extension also handle save/restore to disk.
>
> So the question is more which distros are likely to ship
> new QEMU 9.2, and also still need the ability to incoming
> migrate from an older version of their distro where 2.12
> (or a downstream equiv) was a fully supported machine type.

From Cedric's list, they are ~2018 vintage. I don't know if
there is upstream policy on this, but 2025 seems reasonable
to remove support for live migration from then.

Thanks,
Nick