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

[Mark Cave-Ayland]

On 04/04/2023 15: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@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@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?

I'm using a G4 Mac Mini for my KVM experiments running Debian ports which is fairly 
up to date e.g. gcc-12 for building QEMU. Both the mac99 and g3beige machines will 
boot up to the OS X 10.2 installer on my current (custom) 5.1 kernel.

> Unrelated to KVM: Do you happen to know whether there are any problems when running 
> 32-bit guests with TCG with the mac99 or g3beige machine while using qemu-system-ppc64 ?

I'm not sure as I don't run qemu-system-ppc64 on a regular basis, but I have heard 
from people in the past who have happily used it to boot 64-bit Linux.

(goes and turns on the Mac Mini)

A quick test this evening shows that latest git master builds qemu-system-ppc and 
runs fine with -accel=kvm on the Mac Mini, however something now asserts with 
-accel=tcg on startup which didn't happen before:


Thread 1 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault.
tcg_tb_alloc (s=0x1) at ../tcg/tcg.c:1025
1025        tb = (void *)ROUND_UP((uintptr_t)s->code_gen_ptr, align);
(gdb) bt
#0  0x00ad4148 in tcg_tb_alloc (s=0x1) at ../tcg/tcg.c:1025
#1  0x00ad34c8 in tcg_context_init (max_cpus=1) at ../tcg/tcg.c:959
#2  0x00ad34c8 in tcg_init (tb_size=0, splitwx=0, max_cpus=max_cpus@entry=1) at 
../tcg/tcg.c:1010
#3  0x00b3b784 in tcg_init_machine (ms=<optimized out>) at 
../accel/tcg/tcg-all.c:127
#4  0x008dc784 in accel_init_machine (accel=accel@entry=0x159f8c0, ms=0x1538000) at 
../accel/accel-softmmu.c:39
#5  0x00869184 in do_configure_accelerator (opaque=opaque@entry=0xbffff2ac, 
opts=opts@entry=0x159f4f0, errp=errp@entry=0x13694cc <error_fatal>) at 
../softmmu/vl.c:2224
#6  0x00d8e13c in qemu_opts_foreach (list=<optimized out>, func=func@entry=0x869010 
<do_configure_accelerator>, opaque=opaque@entry=0xbffff2ac, errp=errp@entry=0x13694cc 
<error_fatal>)
    at ../util/qemu-option.c:1135
#7  0x0086c3b4 in configure_accelerators (progname=<optimized out>) at 
../softmmu/vl.c:2293
#8  0x0086c3b4 in qemu_init (argc=<optimized out>, argv=<optimized out>) at 
../softmmu/vl.c:3561
#9  0x0060acd4 in main (argc=<optimized out>, argv=<optimized out>) at 
../softmmu/main.c:47


Richard, any thoughts on this at all?


ATB,

Mark.