Re: [RFC PATCH] docs/about/deprecated: Deprecate 32-bit host systems
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é writes: On Mon, Jan 30, 2023 at 11:47:02AM +, Peter Maydell wrote: On Mon, 30 Jan 2023 at 11:44, Thomas Huth 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. 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. Regards, BALATON Zoltan
Re: [RFC PATCH] docs/about/deprecated: Deprecate 32-bit host systems
On Tue, 4 Apr 2023, Cédric Le Goater wrote:
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 ?
We removed rfi support for 64bit machine in QEMU 2.7. Commit a2e71b28e8
("ppc: Fix rfi/rfid/hrfi/... emulation"). So a mac99 machine using a 970
CPU needs a 64 bit kernel. The rfi insn was deleted from the ISA ...
I don't know about that issue but maybe this does not really answer the
question. AFAIK you could still run 32 bit guests with qemu-system-ppc64
and they seem to work. One could still get the qemu-system-ppc -M mac99
machine as qemu-system-ppc64 -M mac99 -cpu G4 but this is very confusing
and nobody could guess it. Other machines should work the same in
qemu-system-ppc64, the only concern is that some defines such as
TARGET_ULONG are different between qemu-system-ppc and qemu-system-ppc64
and it's not known if this could cause any problems. It's more frequently
happens that people try qemu-system-ppc64 -M mac99 when they want a G4 Mac
and get confused that it emulates a G5 Mac instead which does not even
work for anything than a Linux guest.
Regards,
BALATON Zoltan
Re: [RFC PATCH] docs/about/deprecated: Deprecate 32-bit host systems
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é writes: On Mon, Jan 30, 2023 at 11:47:02AM +, Peter Maydell wrote: On Mon, 30 Jan 2023 at 11:44, Thomas Huth 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
Re: [RFC PATCH] docs/about/deprecated: Deprecate 32-bit host systems
On Tue, 4 Apr 2023, 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é writes: On Mon, Jan 30, 2023 at 11:47:02AM +, Peter Maydell wrote: On Mon, 30 Jan 2023 at 11:44, Thomas Huth 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 Another issue I know is that mac99 behaves differently in qemu-system-ppc and qemu-system-ppc64. This is not only confusing users but makes it more difficult to get rid of qemu-system-ppc. I've tried to solve that and sumbitted a patch to start deprecating these but I could not get that merged. That thread ended here: https://lists.nongnu.org/archive/html/qemu-ppc/2023-01/msg00406.html Regards, BALATON Zoltan
Re: [PATCH v2 07/18] hw/ide/piix: Ensure IDE output IRQs are wired at realization
On Mon, 20 Feb 2023, Bernhard Beschow wrote: IIUC, QEMU guarantees a deprecation period for at least two major versions. So if we deprecated user-creatable piix-ide in 8.1, we are not allowed to remove it before 10.1. Let's stick to our rules to give our users a chance to adapt gracefully. I think that's not 2 major releases just 2 releases so in your example could be removed in 9.0. qemu/docs/about/deprecated.rst says: "The feature will remain functional for the release in which it was deprecated and one further release. After these two releases, the feature is liable to be removed." Regards, BALATON Zoltan
