qemu-arm
[Top][All Lists]
Advanced

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

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


From: Alistair Francis
Subject: Re: 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:26:25 +0200

On Tue, May 10, 2022 at 10:07 AM Thomas Huth <thuth@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-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).

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
>
>



reply via email to

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