qemu-system-aarch64 quits with "ERROR:../target/arm/internals.h:953:arm_fi_to_lfsc: code should not be reached"
<!--
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: Arch Linux
- OS/kernel version: Linux cub3d-arch-desktop 7.0.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 17 May 2026 17:23:07 +0000 x86_64 GNU/Linux
- Architecture: x86_64
- QEMU flavor: qemu-system-aarch64
- QEMU version: QEMU emulator version 11.0.50 (built from git)
- QEMU command line:
<!--
Give the smallest, complete command line that exhibits the problem.
If you are using libvirt, virsh, or vmm, you can likely find the QEMU
command line arguments in /var/log/libvirt/qemu/$GUEST.log.
-->
```
I do not have a reproducer which I can share publicly at this time
```
## Emulated/Virtualized environment
- Operating system: Custom
- OS/kernel version: N/A
- Architecture: AArch64
## Description of problem
Apologies for the low quality report, while I have a reproducer I am unable to share it. I will update this with a sharable reproducer if I can create one. Under some situations it is possible to reach `arm_fi_to_lfsc` with an `fi->type` of `ARMFault_Domain` (4). This is probably due to some interaction between AArch32 EL1 and AArch64 EL2.
This specific case involved a AArch64 EL2 hypervisor running an AArch32 EL1 guest. That guest took a "Undefined instruction" exception due to a trapped `MCR`, returned to EL1 and executed an instruction that produced a "data abort", which redirected execution to an EL1 exception handler. That exception handler immediately executed a breakpoint that took an exception to EL2. The abort happened immediately after executing `AT S1E1R` from EL2.
## Steps to reproduce
## Additional information
`-d int` trace leading up to abort:
```
Exception return from AArch64 EL2 to AArch32 EL1 PC 0x42bda544
Taking exception 1 [Undefined Instruction] on CPU 0
...from EL1 to EL2
...with ESR 0x3/0xfea0001
...with SPSR 0x600000d3
...with ELR 0x418e86a8
...to EL2 PC 0x4019b600 PSTATE 0x3c9
[CORE 0] Trapped MCR MPIDR
Exception return from AArch64 EL2 to AArch32 EL1 PC 0x418e86ac
Taking exception 4 [Data Abort] on CPU 0
...from EL1 to EL1
...with ESR 0x25/0x9600003f
...with DFSR 0x89 DFAR 0x47500000
Taking exception 7 [Breakpoint] on CPU 0
...from EL1 to EL2
...with ESR 0x38/0xe2000000
...with SPSR 0xa00001d7
...with ELR 0x40010010
...to EL2 PC 0x4019b600 PSTATE 0x3c9
**
ERROR:../target/arm/internals.h:953:arm_fi_to_lfsc: code should not be reached
Bail out! ERROR:../target/arm/internals.h:953:arm_fi_to_lfsc: code should not be reached
```
Backtrace:
```
__GI_abort () at abort.c:95
95 ABORT_INSTRUCTION;
(gdb) bt
#0 __GI_abort () at abort.c:95
#1 0x00007ffff678f108 in g_assertion_message
(domain=domain@entry=0x0, file=file@entry=0x555558030b60 "../target/arm/internals.h", line=line@entry=953, func=func@entry=0x555558030fe0 <__func__.3> "arm_fi_to_lfsc", message=message@entry=0x7c2fe455fe90 "code should not be reached") at ../glib/glib/gtestutils.c:3478
#2 0x00007ffff68068a9 in g_assertion_message_expr
(domain=domain@entry=0x0, file=file@entry=0x555558030b60 "../target/arm/internals.h", line=line@entry=953, func=func@entry=0x555558030fe0 <__func__.3> "arm_fi_to_lfsc", expr=expr@entry=0x0)
at ../glib/glib/gtestutils.c:3504
#3 0x0000555557005c40 in arm_fi_to_lfsc (fi=<optimized out>) at ../target/arm/internals.h:953
#4 0x0000555557006a59 in do_ats_write
(env=env@entry=0x7f2fe4400870, value=value@entry=1196425216, prot_check=prot_check@entry=1, mmu_idx=mmu_idx@entry=ARMMMUIdx_Stage1_E1, ss=<optimized out>) at ../target/arm/tcg/cpregs-at.c:155
#5 0x0000555557008207 in ats_write64 (env=0x7f2fe4400870, ri=0x7ccfe44279e0, value=1196425216)
at ../target/arm/tcg/cpregs-at.c:356
#6 0x00007bffa12af337 in code_gen_buffer ()
#7 0x000055555643e365 in cpu_tb_exec
(cpu=cpu@entry=0x7f2fe43fc800, itb=itb@entry=0x7bffa0d01d40 <code_gen_buffer+5250323>, tb_exit=tb_exit@entry=0x7bfd981fdab0) at ../accel/tcg/cpu-exec.c:439
#8 0x000055555643f1be in cpu_loop_exec_tb
(cpu=0x7f2fe43fc800, tb=0x7bffa0d01d40 <code_gen_buffer+5250323>, pc=<optimized out>, last_tb=<synthetic pointer>, tb_exit=<optimized out>) at ../accel/tcg/cpu-exec.c:889
#9 cpu_exec_loop (cpu=cpu@entry=0x7f2fe43fc800, sc=sc@entry=0x7bfd970d1d20) at ../accel/tcg/cpu-exec.c:999
#10 0x00005555564406bd in cpu_exec_setjmp (cpu=cpu@entry=0x7f2fe43fc800, sc=0x7bfd970d1d20)
at ../accel/tcg/cpu-exec.c:1016
#11 0x0000555556441a59 in cpu_exec (cpu=cpu@entry=0x7f2fe43fc800) at ../accel/tcg/cpu-exec.c:1042
#12 0x000055555647e8f8 in tcg_cpu_exec (cpu=cpu@entry=0x7f2fe43fc800) at ../accel/tcg/tcg-accel-ops.c:82
#13 0x000055555647f135 in mttcg_cpu_thread_fn (arg=0x7f2fe43fc800) at ../accel/tcg/tcg-accel-ops-mttcg.c:94
#14 0x0000555557b0749d in qemu_thread_start (args=args@entry=0x7c2fe44f2c30)
at ../util/qemu-thread-posix.c:414
#15 0x00007ffff78618d9 in asan_thread_start (arg=0x7fffe4504000)
at /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_interceptors.cpp:246
#16 0x00007ffff44981b9 in start_thread (arg=<optimized out>) at pthread_create.c:454
#17 0x00007ffff451d21c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
```
<!--
The line below ensures that proper tags are added to the issue.
Please do not remove it.
-->
issue