blob: 769b27d5fd7f58db06580da5129586e108eb7f3a (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, I need to classify this QEMU bug report as either user-mode or system-mode related. Let me go through the details.
The problem occurs when running qemu-system-x86_64, which immediately crashes due to a mutex initialization assertion failure. The error points to an issue in os_setup_limits() function within os-posix.c.
Looking deeper, it's about the setrlimit() syscall behaving differently on macOS compared to Linux. On macOS, setting RLIM_NOFILE with rlim_cur = RLIM_INFINITY is no longer allowed; instead, they recommend using min(OPEN_MAX, rlim_max). The code in QEMU was setting nofile.rlim_cur equal to nofile.rlim_max without considering this restriction.
The function os_setup_limits() is part of the operating system setup for resource limits. This suggests it's handling low-level system resources, which relates to how the emulator interacts with the host OS's kernel and system services.
Since setrlimit() deals with system-wide resource limits and requires higher privileges (usually root or admin), this indicates that the issue is at a lower level than user applications. It involves system calls that affect the entire process and potentially other processes, which are more in line with system-mode operations.
Therefore, this bug is related to how QEMU interacts with system-level resources on macOS, making it a system-mode issue.
</think>
The issue relates to handling of system resource limits using setrlimit(), affecting system-level interactions.
system
|