blob: b99e1dbe09f393af95a3681f6ad925a2c47d1ae7 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, so I'm trying to figure out whether this QEMU crash is a user-mode or system-mode issue. Let's break down the information provided.
The problem happens when running QEMU v8.0.0 in TCG mode on Windows. The crash occurs at atomic_common.c.inc:60 in the function CMPXCHG_HELPER(cmpxchgo_le, Int128). From what I know, TCG is QEMU's translation-based CPU emulator, which runs in user space, not requiring kernel privileges.
Looking at the steps to reproduce, it only happens on Windows when using more than one SMP (symmetric multiprocessing) parameter. On Linux with the same setup, there's no issue. This suggests something specific about how Windows handles concurrency or atomic operations compared to Linux.
The fact that using gdb doesn't reproduce the problem is interesting. Maybe because gdb alters the process execution in a way that avoids the race condition or timing issue causing the crash.
The bug was introduced in QEMU 8.0.0 after a patch, so it's likely related to changes in how atomic operations are handled across multiple threads on Windows. Since TCG runs user-mode code and handles thread synchronization, this points towards a user-space issue rather than something involving system calls or device drivers.
Also, since the problem relates to multi-threading with SMP, which involves multiple CPUs emulated by QEMU, it's about how these threads interact within the application itself—definitely user mode.
</think>
user
|