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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Dec 03, 2024 at 10:59:24AM +0100, Philippe Mathieu-Daudé wrote:
> Hi Andrea,
> 
> On 3/12/24 10:47, 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
> 
> I'm confused by the "machines" description used for user emulation.

It is referring to the host machines, being able (or not) to
run 32-bit usermode code on 64-bit host kernel.

> 
> > 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.
> 
> We have definitions such ELF_ARCH/ELF_PLATFORM/ELF_MACHINE to
> parse ELF header and select the best CPU / flags. Maybe RISC-V
> lacks them?

Is that relevant, as we're not runing QEMU code at all in
the problematic scenario ?

Currently the script below will skip generating a binfmt
rule for riscv32, when on a riscv64 host. Thus qemu-riscv32
will never get called, and the kernel will try & fail to
run riscv32 binaries natively.

This change would make us generate riscv32 binfmt rules
and thus use qemu-riscv32 on riscv64 hosts for linux-user.


Separatley this from patch, we should also consider whether
it is time to do the same for aarch64/arm7.

If I look at this page:

  https://gpages.juszkiewicz.com.pl/arm-socs-table/arm-socs.html

and sort by 'announced' to see msot recent CPUs first, then
almost all of them have "NO" in the "aarch32 support" column.

IOW, on modern aarch64 CPUs, qemu-arm is the only viable way
to run 32-bit usermode binaries AFAICT, and suggests we ought
to be creating a binfmt rule for that on aarch64 hosts.

> BTW we should expose that for linux-user as target_arch_elf.h,
> like bsd-user does, that would reduce all these #ifdef'ry in
> linux-user/elfload.c...
> 
> > 
> > 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.
> 
> Does this patch aim for 9.2? Otherwise FYI  I'm working on unifying
> 32/64-bit targets, maybe for 10.0...

Well in Fedora we'll backport it to 9.2 at least, and from that
POV I'd consider it stable-9.2 material if accepted here.

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

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

> > 
> > diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
> > index 6ef9f118d9..e38b767c24 100755
> > --- a/scripts/qemu-binfmt-conf.sh
> > +++ b/scripts/qemu-binfmt-conf.sh
> > @@ -110,11 +110,11 @@ hppa_family=hppa
> >   riscv32_magic='\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xf3\x00'
> >   riscv32_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
> > -riscv32_family=riscv
> > +riscv32_family=riscv32
> >   riscv64_magic='\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xf3\x00'
> >   riscv64_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
> > -riscv64_family=riscv
> > +riscv64_family=riscv64
> >   xtensa_magic='\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x5e\x00'
> >   xtensa_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
> > @@ -168,9 +168,6 @@ qemu_get_family() {
> >       sparc*)
> >           echo "sparc"
> >           ;;
> > -    riscv*)
> > -        echo "riscv"
> > -        ;;
> >       loongarch*)
> >           echo "loongarch"
> >           ;;
> 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|