1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<think>
Okay, I'm trying to figure out whether this QEMU bug is related to user-mode or system-mode. Let me start by understanding the problem description.
The user reports that when running a Valheim dedicated server using QEMU User on an x86_64 host, the process hangs after encountering a "futex function not implemented" error. The strace shows a futex call with FUTEX_PRIVATE_FLAG|FUTEX_UNLOCK_PI returning errno 38 (Function not implemented). Then, when they interrupt it with SIGINT, another futex call is interrupted.
The steps to reproduce involve installing SteamCMD and the Valheim server, then running it under QEMU. The issue was first seen on a Raspberry Pi ARM64 host using Ubuntu's QEMU 5.2.0, but also reproduced on an x86 Fedora with a QEMU master build.
Looking at the additional info, they mention cross libraries installed for AMD64. So, the problem seems to be when running an x86_64 binary under QEMU on different architectures.
Now, considering how QEMU works: There's system-mode emulation where QEMU emulates a full OS, including kernel and hardware. In user-mode (qemu-x86_64), it translates syscalls from the guest to the host's syscalls.
Futex is a Linux syscall used for synchronization between threads. If the futex implementation in QEMU's user-mode isn't handling certain flags or operations correctly, this could cause hangs because the function isn't implemented, leading to the process waiting indefinitely.
Since the error occurs when running under QEMU User (x86_64), which translates syscalls without a full OS emulation, it's likely a problem in how QEMU handles futex calls. This suggests that the issue is within user-mode because it directly relates to syscall translation and handling, not lower-level hardware or system operations.
In contrast, system-mode issues would involve things like device drivers, kernel interactions beyond syscall translation, or hardware emulation problems. Here, the problem is about a specific syscall not being properly implemented in QEMU's user-mode, so it falls under user-mode.
</think>
The issue relates to how QEMU translates futex syscalls in user-mode, indicating a problem within the user-mode component.
user
|