On Mon, 6 Jan 2025 at 11:58, Daniel P. Berrangé <berra...@redhat.com> wrote: > > On Mon, Jan 06, 2025 at 11:47:00AM +0000, Peter Maydell wrote: > > On Mon, 6 Jan 2025 at 01:29, Alistair Francis <alistai...@gmail.com> wrote: > > > > > > On Fri, Jan 3, 2025 at 2:04 AM Andrea Bolognani <abolo...@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 <davi...@rivosinc.com> > > > > > Thanks: Daniel P. Berrangé <berra...@redhat.com> > > > > > Signed-off-by: Andrea Bolognani <abolo...@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. > > 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 > > > 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. > > The other thing is that qemu-binfmt-conf.sh is not really the right > place to decide this, as we can't assume it is being run on the machine > that QEMU will be deployed on. eg in distro case, qemu-binfmt-conf.sh > may be run in a build farm to statically generate files. > > Any conditional loading of binfmt rules would required extra magic to be > implemented by systemd, or would have to be done by the user selectively > installing different packages to omit the binfmt rules they don't want.
If the kernel supported this via a binfmt flag, it wouldn't need systemd-specific magic, user intervention, or for qemu-binfmt-conf.sh to be running on the target machine. (But of course there's the "does anybody care enough to implement that" problem plus the long delay of actually deploying kernels that know about the flag...) thanks -- PMM
