All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Francis <alistair23@gmail.com>
To: Thomas Huth <thuth@redhat.com>
Cc: "Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	"Fabiano Rosas" <farosas@linux.ibm.com>,
	muriloo@linux.ibm.com,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Daniel Henrique Barboza" <danielhb413@gmail.com>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	mopsfelder@gmail.com, "open list:New World" <qemu-ppc@nongnu.org>,
	"Cédric Le Goater" <clg@kaod.org>, qemu-arm <qemu-arm@nongnu.org>,
	qemu-RISC-V <qemu-riscv@nongnu.org>
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	[thread overview]
Message-ID: <CAKmqyKNXMsVnH1y__abw7YaompT5MLXFn0Pvr+d4ddwXeP_VTw@mail.gmail.com> (raw)
In-Reply-To: <472e45e8-319b-ad48-3afa-0dfa74e6ad20@redhat.com>

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	other threads:[~2022-05-10  8:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-29 23:31 [PATCH] mos6522: fix linking error when CONFIG_MOS6522 is not set Murilo Opsfelder Araujo
2022-05-02  9:43 ` Mark Cave-Ayland
2022-05-02 13:36   ` Murilo Opsfelder Araújo
2022-05-03 14:06     ` Fabiano Rosas
2022-05-04  7:16       ` Mark Cave-Ayland
2022-05-04 14:26         ` Fabiano Rosas
2022-05-04 14:48           ` Mark Cave-Ayland
2022-05-10  8:03             ` QEMU 32-bit vs. 64-bit binaries (was: [PATCH] mos6522: fix linking error when CONFIG_MOS6522 is not set) Thomas Huth
2022-05-10  8:26               ` Alistair Francis [this message]
2022-05-10  8:54               ` QEMU 32-bit vs. 64-bit binaries Markus Armbruster
2022-05-10  9:01                 ` Thomas Huth
2022-05-10  9:14                   ` Peter Maydell
2022-05-10  9:22                     ` Dr. David Alan Gilbert
2022-05-10  9:31                       ` Thomas Huth
2022-05-10  9:47                         ` Peter Maydell
2022-05-10 10:14                         ` BALATON Zoltan
2022-05-10 12:20                         ` Gerd Hoffmann
2022-05-10 12:25                           ` Peter Maydell
2022-05-04  7:10     ` [PATCH] mos6522: fix linking error when CONFIG_MOS6522 is not set Mark Cave-Ayland
2022-05-04 13:16       ` Murilo Opsfelder Araújo
2022-05-04 14:32         ` Mark Cave-Ayland
2022-05-05  1:24           ` Murilo Opsfelder Araújo
2022-05-05  8:19             ` Mark Cave-Ayland
2022-05-10  8:40               ` QEMU with reduced amount of machines in the config (was: [PATCH] mos6522: fix linking error when CONFIG_MOS6522 is not set) Thomas Huth
2022-05-06 23:44   ` [PATCH] mos6522: fix linking error when CONFIG_MOS6522 is not set Murilo Opsfelder Araújo
2022-05-08  9:30     ` Mark Cave-Ayland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKmqyKNXMsVnH1y__abw7YaompT5MLXFn0Pvr+d4ddwXeP_VTw@mail.gmail.com \
    --to=alistair23@gmail.com \
    --cc=clg@kaod.org \
    --cc=danielhb413@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=farosas@linux.ibm.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=mopsfelder@gmail.com \
    --cc=muriloo@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.