blob: 70b201fab48564ed587fe7776420ae46793b3770 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<think>
Alright, I need to figure out whether this QEMU issue is a user-mode or system-mode problem. Let's break it down.
The user mentioned that the `set_robust_list` syscall isn't implemented in QEMU for any Linux platform. They provided a program that uses `syscall(__NR_set_robust_list)` which works on native Linux but returns "Function not implemented" in QEMU.
I know that `set_robust_list` is used by glibc's robust mutex implementation, particularly in NPTL (Native POSIX Thread Library). This function helps manage mutexes that can be shared across processes and handles cases where a process holding the lock dies unexpectedly.
Looking at the provided code, it's a userland program. It doesn't require any special privileges beyond what a normal application would have. The issue arises when this program runs in QEMU; the syscall isn't handled correctly.
QEMU has two main modes: user-mode emulation and system-mode (like KVM). In user-mode, QEMU emulates the CPU instructions but runs on top of the host OS for syscalls. System-mode is more like a full VM with its own kernel.
Since `set_robust_list` is a syscall that needs to be handled by the target environment's OS layer, and QEMU in user-mode doesn't implement it, this suggests it's a user-mode issue. The problem isn't with hardware or higher-level system services but rather how QEMU handles syscalls in its user emulation.
So, this bug is related to how QEMU emulates syscalls for userland applications, making it a 'user' mode problem.
</think>
The issue pertains to the handling of a syscall in QEMU's user-mode emulation. Since `set_robust_list` isn't implemented there and affects userland applications, it's classified as a user-mode bug.
user
|