## Host environment - Operating system: NixOS 26.05 - OS/kernel version: 6.18.34 - Architecture: x86 - QEMU flavor: qemu-system-x86_64; qemu-system-aarch64 - QEMU version: ``` QEMU emulator version 11.1.50 28e7aad52202 ("Merge tag 'pull-target-arm-20260915' of https://gitlab.com/pm215/qemu into staging") ``` - QEMU command line: ``` qemu-system-aarch64 -machine virt -cpu cortex-a57 \ -drive if=pflash,file=aarch64.rom,readonly=off -nographic ``` ## Emulated/Virtualized environment - Operating system: Bare metal; U-Boot - OS/kernel version: N/A - Architecture: reproducers on x86 and aarch64 ## Description of problem I'm writing a test to validate UEFI firmware capsule update flow using U-Boot. When using tcg, I discovered that the tb cache is never invalidated after writing the firmware update to pflash. Data fetches get updated correctly, but the tb cache doesn't get invalidated. This causes program to fail in inconsistent/unexpected ways. I'm able to observe this issue on both x86_64 and aarch64 tcg. I can create a workaround by calling `queue_tb_flush(cpu);` in `tcg_cpu_reset_hold()`, but this only works because UEFI capsule updates always perform a system reset. This also helped me confirm that this really seems to be an issue with the tb cache. ## Steps to reproduce Describing a reproducer using U-Boot requires a bit of configuration to get capsule updates enabled and generate a capsule; I was able to create a simpler reproducer in a \~100 lines of assembly for aarch64. Instructions and the repro are uploaded to https://github.com/elliotberman/qemu-pflash-stale-tb-repro The reproducer script moves a constant into x0, updates the pflash so the instruction moves a different constant into x0 (different instruction), re-run the instruction, and **observe that the original constant is still moved into x0, even though the pflash is updated if I dump the memory.** The reproducer has a gdb script with some macros set up to show the issue. The basic steps are: 1. `make qemu-aarch64` to launch qemu-system-aarch64 from PATH using the demo pflash image 2. `make gdb-aarch64` to launch `aarch64-unknown-linux-gnu-gdb` with the walkthrough script 3. Sample output: ``` Reading symbols from aarch64/repro.elf... (No debugging symbols found in aarch64/repro.elf) Remote debugging using :1234 0x0000000000000000 in _start () pflash stale-TB reproducer walkthrough loaded. Run `boot` macro to run the first few instructions before modifying the pflash. (gdb) boot [boot] Running from reset to the first dispatch() call... Hardware assisted breakpoint 1 at 0x40000 Breakpoint 1, 0x0000000000040000 in dispatch () -- pass 1: about to reflash -- x0 = 0x46 (expect 0x46) current disassembly of _start (still pre-reflash): Dump of assembler code from 0x0 to 0x8: 0x0000000000000000 <_start+0>: mov x0, #0x46 // #70 0x0000000000000004 <_start+4>: b 0x40000 <dispatch> End of assembler dump. Run `reflash` macro to continue execution through reprogramming the flash. (gdb) reflash [reflash] Reprogramming flash (erase, program, Read Array)... Hardware assisted breakpoint 2 at 0x4000003c Breakpoint 2, 0x000000004000003c in reflash_done () -- flash storage now shows the NEW instruction -- $pc = 0x4000003c (inside the RAM copy of do_reflash -- not back in _start yet) $x0 = 0x0 (reset back to 0 so we can observe instruction) disassembly of _start's address now (a plain data read -- always correct): Dump of assembler code from 0x0 to 0x8: 0x0000000000000000 <_start+0>: mov x0, #0x53 // #83 0x0000000000000004 <_start+4>: b 0x40000 <dispatch> End of assembler dump. Run `reenter` macro to continue execution through re-entering _start and see whether execution picked up the change. (gdb) reenter [reenter] Continuing through re-entry (goto or reset) to dispatch()'s escape hatch... Breakpoint 1, 0x0000000000040000 in dispatch () -- pass 2: escape hatch entered -- x0 = 0x46 (marker execution actually produced THIS boot) 0x46 => STALE TB executed: this is the bug. 0x53 => fresh translation, no staleness. disassembly of _start's address (a plain data read -- always correct): Dump of assembler code from 0x0 to 0x8: 0x0000000000000000 <_start+0>: mov x0, #0x53 // #83 0x0000000000000004 <_start+4>: b 0x40000 <dispatch> End of assembler dump. Walkthrough complete. ``` ## Additional information I used Claude to explore the code base and challenge/strengthen the hypothesis about the tb cache issue. I've left the notes I generated with it in https://github.com/elliotberman/qemu-pflash-stale-tb-repro/blob/main/LLM_NOTES.md I'd be happy to submit a patch, but I wasn't sure if I should extend pflash_set_to_read_array_mode() or memory_region_rom_set_device_set_romd() to also invalidate the tb cache, or something else entirely.