architecture: 0.718
arm: 0.664
graphic: 0.523
semantic: 0.446
device: 0.444
performance: 0.428
mistranslation: 0.386
user-level: 0.325
PID: 0.322
debug: 0.295
network: 0.258
vnc: 0.254
x86: 0.249
permissions: 0.249
virtual: 0.236
assembly: 0.236
i386: 0.231
VMM: 0.225
ppc: 0.223
TCG: 0.213
socket: 0.210
peripherals: 0.198
files: 0.194
risc-v: 0.185
register: 0.185
boot: 0.184
hypervisor: 0.141
KVM: 0.132
kernel: 0.132

older programs running under qemu-aarch64 segfaults
Description of problem:
Numerous aarch64 programs segfaults when run under qemu-aarch64.
Steps to reproduce:
1. Install an arm64 chroot (with working qemu-aarch64 binfmt_misc setup):
```
debootstrap --variant=minbase --arch=arm64 jessie /tmp/jessie-arm64/ http://archive.debian.org/debian
or
debootstrap --variant=minbase --arch=arm64 xenial /tmp/xenial-arm64/ http://ports.ubuntu.com/
```
2. build qemu-aarch64; cp qemu-aarch64 /tmp/jessie-arm64/
3. chroot /tmp/jessie-arm64/
4. ./qemu-aarch64 /bin/ls
```
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault 
```
Additional information:
Old userspace (eg Debian jessie, Ubuntu xenial) does not work within qemu 8.1-rc2 aarch64 linux-user emulation, since commit 59b6b42cd3446862567637f3a7ab31d69c9bef51 .  My guess is that old userspace isn't prepared for recent CPU features, but it still smells strange.

Not all programs segfaults. dash works, ls or bash does not.

A chroot is easier in this case, since many old programs don't run inside current environment, like asserting while reading locale-specific information.  To run debootstrap and to enter the resulting chroot, a working qemu-aarch64 binfmt_misc setup is needed.

Reverting the mentioned commit makes everything work again.