QEMU 32-bit vs. 64-bit binaries (was: [PATCH] mos6522: fix linking error when CONFIG_MOS6522 is not set)

[Thomas Huth]

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.

 Thomas