1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, I'm trying to figure out how to classify this bug report about QEMU failing when compiling Erlang/OTP 25 in user mode on AArch64. Let me read through the problem description carefully.
So, the issue is that when using user mode emulation with QEMU, there's a segfault during the compilation of Erlang. The developers mentioned that this doesn't happen in system mode. They've tracked it down to something related to how QEMU handles JIT code regions and memory protection.
The explanation says that QEMU dynamically translates guest code to the host architecture. When the guest overwrites code, the translation should be invalidated. For Erlang's JIT, they use two regions: one executable but not writable, and another writable but not executable. Both point to the same physical memory. Writes to the writable region are supposed to reflect in the executable one through some mechanism.
The problem arises because QEMU isn't handling this correctly. In system mode, QEMU emulates the MMU and notices when the writable region is modified, so it invalidates the executable translations properly. However, in user mode, QEMU uses mprotect with PROT_READ on all code regions after translation. It relies on a signal handler to invalidate translations when writes occur. But since the code is only being written to the writable region (not the executable one), the translations aren't invalidated as they should be.
The developers note that QEMU ignores certain instructions (IC IVAU / ISB) meant to tell the processor about code changes, and this causes issues specifically in user mode.
Now, looking at the categories: instruction, syscall, runtime. The problem isn't directly about a faulty instruction being executed or an error with system calls. It seems more like an issue that happens during runtime when QEMU is handling memory protections and translation invalidation incorrectly. So it's related to how QEMU manages the JIT code regions and responds to writes in user mode.
Therefore, I think this bug falls under the "runtime" category because it's about how the program behaves at runtime when certain conditions are met (like writing to specific memory regions without proper handling), leading to a segfault.
</think>
runtime
|