On Tue, May 10, 2022 at 10:07 AM Thomas Huth <th...@redhat.com> wrote: > > 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).
For RISC-V we are slowly moving towards riscv64 being a superset of riscv32, similar to the other architectures > > 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. That was the eventual long term plan for RISC-V, then we can have a single binary for everything > > 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. Agreed! Alistair > > Thomas > >
