On 04/05/2022 16.48, Mark Cave-Ayland wrote:
On 04/05/2022 15:26, Fabiano Rosas wrote:
Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> writes:
On 03/05/2022 15:06, Fabiano Rosas wrote:
Murilo Opsfelder Araújo <muri...@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
