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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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@xxxxxxxxxx> 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.




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux