[RFC PATCH] docs/about/deprecated: Deprecate 32-bit host systems

[Thomas Huth]

On 05/04/2023 13.54, BALATON Zoltan wrote:
> On Wed, 5 Apr 2023, Thomas Huth wrote:
>> On 04/04/2023 17.42, BALATON Zoltan wrote:
>>> On Tue, 4 Apr 2023, Cédric Le Goater wrote:
>>>> [ adding Zoltan ]
>>>>
>>>> On 4/4/23 16:00, Thomas Huth wrote:
>>>>> On 05/02/2023 23.12, Mark Cave-Ayland wrote:
>>>>>> On 30/01/2023 20:45, Alex Bennée wrote:
>>>>>>
>>>>>>> Daniel P. Berrangé <berrange at redhat.com> writes:
>>>>>>>
>>>>>>>> On Mon, Jan 30, 2023 at 11:47:02AM +0000, Peter Maydell wrote:
>>>>>>>>> On Mon, 30 Jan 2023 at 11:44, Thomas Huth <thuth at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Testing 32-bit host OS support takes a lot of precious time during 
>>>>>>>>>> the QEMU
>>>>>>>>>> contiguous integration tests, and considering that many OS vendors 
>>>>>>>>>> stopped
>>>>>>>>>> shipping 32-bit variants of their OS distributions and most 
>>>>>>>>>> hardware from
>>>>>>>>>> the past >10 years is capable of 64-bit
>>>>>>>>>
>>>>>>>>> True for x86, not necessarily true for other architectures.
>>>>>>>>> Are you proposing to deprecate x86 32-bit, or all 32-bit?
>>>>>>>>> I'm not entirely sure about whether we're yet at a point where
>>>>>>>>> I'd want to deprecate-and-drop 32-bit arm host support.
>>>>>>>>
>>>>>>>> Do we have a feeling on which aspects of 32-bit cause us the support
>>>>>>>> burden ? The boring stuff like compiler errors from mismatched integer
>>>>>>>> sizes is mostly quick & easy to detect simply through a cross compile.
>>>>>>>>
>>>>>>>> I vaguely recall someone mentioned problems with atomic ops in the 
>>>>>>>> past,
>>>>>>>> or was it 128-bit ints, caused implications for the codebase ?
>>>>>>>
>>>>>>> Atomic operations on > TARGET_BIT_SIZE and cputlb when
>>>>>>> TCG_OVERSIZED_GUEST is set. Also the core TCG code and a bunch of the
>>>>>>> backends have TARGET_LONG_BITS > TCG_TARGET_REG_BITS ifdefs peppered
>>>>>>> throughout.
>>>>>>
>>>>>> I am one of an admittedly small group of people still interested in 
>>>>>> using KVM-PR on ppc32 to boot MacOS, although there is some interest 
>>>>>> on using 64-bit KVM-PR to run super-fast MacOS on modern Talos hardware.
>>>>>>
>>>>>>  From my perspective losing the ability to run 64-bit guests on 32-bit 
>>>>>> hardware with TCG wouldn't be an issue, as long as it were still 
>>>>>> possible to use qemu-system-ppc on 32-bit hardware using both TCG and 
>>>>>> KVM to help debug the remaining issues.
>>>>>
>>>>>   Hi Mark!
>>>>>
>>>>> Just out of curiosity (since we briefly talked about 32-bit KVM on ppc 
>>>>> in today's QEMU/KVM call - in the context of whether qemu-system-ppc64 
>>>>> is a proper superset of qemu-system-ppc when it comes to building a 
>>>>> unified qemu-system binary): What host machine are you using for 
>>>>> running KVM-PR? And which QEMU machine are you using for running macOS? 
>>>>> The mac99 or the g3beige machine?
>>>>
>>>> Zoltan, what about the pegasos2 and sam460ex machines ? can they be run 
>>>> under KVM ?
>>>
>>> I don't know as I don't have PPC hardware to test on but theoretically 
>>> they should work. Although BookE KVM was dropped from Linux I think so 
>>> sam460ex could only work with an old kernel on a BookE host which is now 
>>> rare 
>> [...]
>>
>> Thanks for your explanations, that indeed helps to understand the situation!
>>
>> But are you sure about the BookE KVM removal in the Linux kernel? ... when 
>> I look at the arch/powerpc/kvm/ folder there, I can still see some files 
>> there with "booke" in the name?
> 
> No, I'm not sure but I think KVM on PPC440 (which is used by sam460ex) is 
> likely not working properly. What's there may work on newer cores such as 
> e500 and later but not sure if that can run PPC440 code. I never heard 
> anyone successfully getting sam460ex work with KVM but that may also be 
> because real PPC440 hosts are rare.

Ok, if nobody is really using KVM on PPC440 anymore, we should mark that as 
deprecated in QEMU, I think.

> But if the question is if we still need 32 bit PPC host I think we do for 
> now as that's the only way to run 32bit guests with G3 and G4 until the 
> issues which prevent them to run on 64bit host kernel are fixed.

Yes, understood. As long as 32-bit KVM is in use on ppc, we've got to keep 
the code around.

  Thomas