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

[Andrea Bolognani <abologna@redhat.com>]

On Mon, Jan 06, 2025 at 11:57:58AM +0000, Daniel P. Berrangé wrote:
> On Mon, Jan 06, 2025 at 11:47:00AM +0000, Peter Maydell wrote:
> > On Mon, 6 Jan 2025 at 01:29, Alistair Francis <alistair23@gmail.com> wrote:
> > > 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.
>
> Arm is a bigger problem as historically there genuinely was a
> non-trivial set of CPUs with 32-on-64 support in HW.
>
> IIUC, the riscv situation is much less likely to be a real problem

Exactly.

My understanding is that, while 64-bit RISC-V CPUs that can natively
run 32-bit applications are theoretically possible, no such CPU
actually exists right now.

Even if it did exist, distros would have to set up things to support
this scenario, which they don't.

So in the current situation we're effectively making it impossible to
run riscv32 binaries on riscv64 for the benefit of a hypotetical
scenario.

> As a immediate bandaid, I'd suggest that qemu-binfmt-conf.sh could keep
> its current logic as the default, and have a switch "--32-on-64" [1] to
> tell it to generate the binfmt for 32-bit arch, even if 64-bit arch
> could have 32-bit support.
>
> Distros/users could then choose whether to pass --32-on-64 when statically
> generating the binfmt files.

While I'm still convinced that this patch could be safely applied
as-is, I'd be happy to go with your proposed approach if doing so
would help move things forward.

-- 
Andrea Bolognani / Red Hat / Virtualization