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é <berra...@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 <th...@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.
