On Tue, Dec 03, 2024 at 07:57:14AM -0600, Richard Henderson wrote: > On 12/3/24 04:35, Peter Maydell wrote: > > On Tue, 3 Dec 2024 at 10:19, Daniel P. Berrangé <berra...@redhat.com> wrote: > > > 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. > > > > What happens if you have a host CPU that *does* support 32-bit > > natively and you also register the binfmt rule? Does the > > host kernel prefer to execute natively or does it invoke > > QEMU? I don't think we want to roll out something that > > silently downgrades native execution to emulation... > > The registered rule applies and the kernel invokes qemu.
This is all quiet difficult from a distro POV, but not QEMU's fault. We want to install the binfmt rules in a way that we "do the right thing" regardless of hardware out of the box. The systemd logic for loading binfmt rules is unconditional, loading everything from /usr/lib/binfmt.d, but we need a way to make things conditional on the lack of support for aarch32 on the currently running platform. 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 :|
