Okay, so I'm trying to figure out whether this bug in QEMU is a user-mode issue or a system-mode issue. Let me start by understanding the context. The code provided uses RISC-V instructions. The main instruction causing problems is sfence.vma. From what I know, sfence.vma flushes the TLB (Translation Lookaside Buffer) entries for a specific virtual address range. Flushing the TLB should cause the translation block to end because it invalidates existing translations. Looking at the code, before writing to SATP, the PC is running in physical address mode. The stvec is set to label 1 with a virtual prefix, and the virtual address mapping is set up in early_pgtbl. After setting SATP, there's a page fault expected, which should redirect execution to label 1. But according to the user, when this code runs normally (not single-stepping), it crashes because the translation block isn't ending after sfence.vma. The stvec is being set to trap_s instead of jumping to label 1 as intended. This causes repeated exceptions and the program crashes. In single-step mode, it works correctly, with PC setting to label 1. So the issue arises only when running normally. The user tried modifying QEMU's code by ending the translation block after sfence.vma, which helped in their testing but they're unsure if that's correct. Now, considering whether this is a user-mode or system-mode issue: User-mode typically deals with applications and less privileged operations, while system-mode involves higher privileges, like device handling and OS-level functions. Since sfence.vma is a system instruction (used for flushing TLB entries) and the code is dealing with SATP and stvec which are part of the RISC-V privilege model, this seems to involve system-level operations. The problem affects how exceptions are handled after modifying MMU settings, which is definitely part of the system's responsibility. Therefore, this bug is likely related to system-mode operations. system