<!-- This is the upstream QEMU issue tracker. If you are able to, it will greatly facilitate bug triage if you attempt to reproduce the problem with the latest qemu.git master built from source. See https://www.qemu.org/download/#source for instructions on how to do this. QEMU generally supports the last two releases advertised on https://www.qemu.org/. Problems with distro-packaged versions of QEMU older than this should be reported to the distribution instead. See https://www.qemu.org/contribute/report-a-bug/ for additional guidance. If this is a security issue, please consult https://www.qemu.org/contribute/security-process/ --> ## Host environment - Operating system: Debian - OS/kernel version: Linux raspberrypi 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux - Architecture: aarch64 - QEMU flavor: qemu-system-aarch64 - QEMU version: 11.0.50 (built from git) - QEMU command line: ```shell qemu-system-aarch64 -kernel ~/poc --machine virt --cpu cortex-a55 -serial stdio -nographic -monitor none -m 32M ``` ## Emulated/Virtualized environment - Operating system: Custom - OS/kernel version: N/A - Architecture: aarch64 ## Description of problem The `IL` field of `ESR_ELx` should report the length of the trapped instruction, 0 for 16-bit instructions and 1 for 32-bit instructions. When trapping a 16-bit thumb `bkpt #0` (`0x00 0xbe`) the `IL` field reads `1` under TCG. But on real hardware (KVM) it reads `0`. ## Steps to reproduce Running the following: ```shell qemu-system-aarch64 -kernel ~/poc --machine virt --cpu cortex-a55 -serial stdio -nographic -monitor none -m 32M ``` produces this output: ``` panic: Unexpected sync_lower, IL=4, esr e2000000 ``` Whereas running with `-accel kvm` (Tested on a Raspberry PI 4B, BCM2711 / Cortex-A72): ```shell qemu-system-aarch64 -kernel ~/poc --machine virt --cpu host -serial stdio -nographic -monitor none -m 32M -accel kvm ``` produces this output: ``` panic: Unexpected sync_lower, IL=2, esr e0000000 ``` ## Additional information This example is an AArch64 EL1 kernel, with an AArch32 thumb EL0 that executes `bkpt #0` triggering an exception to EL1. This has also been observed with an AArch64 EL2 hypervisor, with an AArch32 thumb EL1. So this affects both `ESR_EL1` and `ESR_EL2` Example binary/source: [poc_for_qemu.zip](/uploads/3b2bf2e2464efabb4f5b48e2641cbe1e/poc_for_qemu.zip) <!-- The line below ensures that proper tags are added to the issue. Please do not remove it. -->