user-level: 0.923 x86: 0.778 graphic: 0.619 device: 0.618 architecture: 0.609 semantic: 0.533 performance: 0.518 ppc: 0.385 boot: 0.358 network: 0.350 permissions: 0.344 assembly: 0.337 socket: 0.330 mistranslation: 0.286 debug: 0.273 PID: 0.265 i386: 0.264 register: 0.239 vnc: 0.230 peripherals: 0.220 VMM: 0.191 virtual: 0.185 risc-v: 0.175 arm: 0.163 files: 0.148 KVM: 0.119 hypervisor: 0.104 kernel: 0.103 TCG: 0.095 -------------------- user-level: 0.989 virtual: 0.820 debug: 0.406 arm: 0.100 architecture: 0.047 performance: 0.039 TCG: 0.024 files: 0.021 register: 0.015 PID: 0.009 semantic: 0.006 network: 0.006 device: 0.004 hypervisor: 0.004 assembly: 0.004 boot: 0.003 socket: 0.002 VMM: 0.002 kernel: 0.002 risc-v: 0.002 peripherals: 0.001 permissions: 0.001 ppc: 0.001 x86: 0.001 KVM: 0.001 vnc: 0.001 graphic: 0.000 mistranslation: 0.000 i386: 0.000 User mode qemu-aarch: SIGGSEGV signal handler works wrong I have a user mode qemu-aarch issue. Program with SIGSEGV signal handler works wrong under qemu-aarch: once the progam handles the SEGV signal, qemu marks the program's page protected, and signal handler gets SEGV on each subsequent memory access instruction within a program. The issue is reproduced on WSL Ubuntu 20.04 under Windows 10, qemu-aarch64 version 5.1.50 The issue is also reproducible on the latest upstream qemu-aarch build. The following workaround disables mprotect call and fixes the issue: https://github.com/BorisUlasevich/qemu/commit/3063d9a64f8395185d65c6b6710d28ee92cd8be5 The issue can be reproduced on OpenJDK which reports SIGSEGV immediately after start. The small reproducer program is attached. The patch is most definitely wrong. The page protection is required to implement self-modifying code, of which a signal trampoline is a subset. Moreover, your test case works for me using both x86_64-linux and aarch64-linux as hosts. There may be a bug, but I suspect it to be within WSL. I have no way to test that one way or another. [Expired for QEMU because there has been no activity for 60 days.]