Re: [PATCH] binfmt: Don't consider riscv{32, 64} part of the same family

[Peter Maydell <peter.maydell@linaro.org>]

On Mon, 6 Jan 2025 at 01:29, Alistair Francis <alistair23@gmail.com> wrote:
>
> On Fri, Jan 3, 2025 at 2:04 AM Andrea Bolognani <abologna@redhat.com> wrote:
> >
> > On Tue, Dec 03, 2024 at 10:47:02AM +0100, Andrea Bolognani wrote:
> > > Currently the script won't generate a configuration file that
> > > sets up qemu-user-riscv32 on riscv64, likely under the
> > > assumption that 64-bit RISC-V machines can natively run 32-bit
> > > RISC-V code.
> > >
> > > However this functionality, while theoretically possible, in
> > > practice is missing from most commonly available RISC-V hardware
> > > and not enabled at the distro level. So qemu-user-riscv32 really
> > > is the only option to run riscv32 binaries on riscv64.
> > >
> > > Make riscv32 and riscv64 each its own family, so that the
> > > configuration file we need to make 32-on-64 userspace emulation
> > > work gets generated.
> > >
> > > Link: https://src.fedoraproject.org/rpms/qemu/pull-request/72
> > > Thanks: David Abdurachmanov <davidlt@rivosinc.com>
> > > Thanks: Daniel P. Berrangé <berrange@redhat.com>
> > > Signed-off-by: Andrea Bolognani <abologna@redhat.com>
> > > ---
> > >  scripts/qemu-binfmt-conf.sh | 7 ++-----
> > >  1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > ping
> >
> > There are already two ACKs so I think we just need a maintainer to
> > pick this up.
>
> We didn't get an answer to the issue of a CPU supporting RV32 and yet
> the kernel still calls QEMU.
>
> I understand this allows things to work out of the box, but seems like
> a disservice to any hardware that does support RV32

There's the same thing on Arm too -- we don't set up qemu-user
aarch32 binfmt-misc on an aarch64 system because the host might
be able to natively execute the aarch32 binary. This is becoming
less true, but we still don't want to silently downgrade
native execution to emulation on the hosts where native execution
used to work.

I'm not sure the best approach here -- ideally we would want to
be able to register a binfmt-misc to the host kernel with "only use
this if you could not already natively execute it", but AFAIK that's
not possible.

-- PMM