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

[Alistair Francis]

On Tue, Jan 7, 2025 at 3:54 AM Andrea Bolognani <abologna@redhat.com> wrote:
>
> 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.

I do think T-HEAD are working on CPUs that do that though

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

Fair point

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

My worry is that in the future there is hardware that can do this and
we are stuck with this decision.

It does seem unlikely that lots of hardware will start supporting RV32

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

That might be the best step, that way we allow distros to decide

Alistair

>
> --
> Andrea Bolognani / Red Hat / Virtualization
>