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@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?
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