[Top][All Lists]

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

QEMU 32-bit vs. 64-bit binaries (was: [PATCH] mos6522: fix linking error

From: Thomas Huth
Subject: QEMU 32-bit vs. 64-bit binaries (was: [PATCH] mos6522: fix linking error when CONFIG_MOS6522 is not set)
Date: Tue, 10 May 2022 10:03:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0

On 04/05/2022 16.48, Mark Cave-Ayland wrote:
On 04/05/2022 15:26, Fabiano Rosas wrote:

Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> writes:

On 03/05/2022 15:06, Fabiano Rosas wrote:

Murilo Opsfelder Araújo <muriloo@linux.ibm.com> writes:
So ppc64-softmmu doesn't quite do what it says on the tin. I think in
the long run we need to revisit the conversation about whether to keep
the 32 & 64 bit builds separate. It is misleading that you're explicitly
excluding ppc-softmmu from the `--target-list`, but a some 32 bit stuff
still comes along implicitly.

Unfortunately for historical reasons it isn't quite that simple: the mac99 machine in hw/ppc/mac_newworld.c is both a 32-bit and a 64-bit machine, but with a different PCI host bridge and a 970 CPU if run from qemu-system-ppc64. Unfortunately it pre-dates my time working on QEMU's PPC Mac machines but I believe it was (is?) capable of
booting Linux, even though I doubt it accurately represents a real machine.

Well, what you describe is fine in my view, the 64-bit machine uses
qemu-system-ppc64. If there is shared code with 32-bit, that is ok.

What I would like to understand is what is the community's direction
with this, do we want:

1) the 64-bit build to include all of the code and have it run all
    machines, or;

2) the 64-bit build to run only 64-bit machines and the 32-bit build to
    run only 32-bit machines.

There are things such as 'target_ulong' that go against #1, and this
thread shows that we're not doing #2 as well.

I know there have been discussions about this in the past but I couldn't
find them in the archives.

Certainly if a 64-bit Mac machine were to be added today, I'd be inclined to copy mac_newworld.c into a separate file and give it a separate machine name for ppc64 to make a clear distinction between the two machines (and allow them to evolve separately). Unfortunately I have no idea as to what the reference machine for the PPC64 Mac machine was supposed to be which makes it harder to decide what to do :(

In my mind it feels like qemu-system-ppc is for 32-bit guests and qemu-system-ppc64 is for 64-bit guests which I believe is consistent with how it currently works with MIPS and ARM (someone feel free to correct me here).

For CPUs that have both, 32-bit and 64-bit variants, we have mixed approaches:

1) For x86_64/i386, aarch64/arm, mips64/mips and ppc64/ppc, the 64-bit variants are a superset of the 32-bit variants, i.e. if you build the 64-bit version, you normally don't need the 32-bit version anymore (see below for the KVM-case where you still might need it).

2) For sparc64/sparc and riscv64/riscv32, the set of machines is distinct between the 64-bit and 32-bit versions (well, riscv has some machines shared, and some machines are different).

I once suggested in the past already that we should maybe get rid of the 32-bit variants in case the 64-bit variant is a full superset, so we can save compile- and test times (which is quite a bit for QEMU), but I've been told that the 32-bit variants are mostly still required for supporting KVM on 32-bit host machines.

But in the long run, I think we rather want to converge everything into one binary (to decrease testing and compilation time) instead of separating stuff into multiple binaries, so IMHO we should not start separating the 32-bit machines into qemu-system-ppc and the 64-bit-only machines into qemu-system-ppc64 now.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]