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é <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?
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 but pegasos2 uses G4 CPU which is more likely to work on a host with
the same CPU but I don't know anybody tested it yet. I know some people
are interested to use it especially on G4 and G5 and some tested the
latter but it does not work due to some differences that should be handled
by KVM-PR but apparently they aren't (e.g. dcbz cache line size which I've
seen debugged and identified by at least two sources that I sent
references to this list before but to my knowledge no fix got upstream in
Linux for this).
AFAIK Mark has a G4 Mac mini on which KVM-PR works and it may also work on
G5 when using 32 bit Kernel but running G4 guest on G5 with 64 bit kernel
does not work. G5 host with 64 bit kernel may work with 64 bit guests but
all Amiga like OSes I'm interested in are 32 bit so they either need 32
bit host kernel, preferably with same CPU as the guest (so G4 for pegasos2
or PPC440 for sam460ex) or fixing the patching and emulation of
instructions in KVM-PR that behave differently between G4 and G5 which
should be possible but nobody seems to have done it or bothered to
upstream it and what's there may be incomplete or buggy.
The only reports I've seen that said it works were either running 32bit
guest on 32bit BookS host or 64bit guest on 64bit BookS host. (A special
case is running 64bit aware 32bit guest such as newer MacOS or MorphOS
versions on 64bit hosts which can run on real G5 so these may run as long
as they correctly identify the CPU they are running on but the G5 Mac
emulation in QEMU currently can't boot these because the machine is not
emulated precisely enough for them.)
Regards,
BALATON Zoltan
