blob: d6b1cdf28b567e7c8192319cdce495973e4715d5 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, so I need to figure out whether this QEMU bug is related to user-mode or system-mode. Let me start by understanding the problem.
The user is trying to run Wine on qemu-i386 on an ARM host. They noticed that with QEMU version 2.6, epoll was broken, but it worked fine in 2.5.1. By bisecting, they found a specific commit (928bed6a057cedd6110e634865e021a24029785a) that caused the issue. Reverting this commit fixed epoll for them.
I need to classify this bug into user-mode or system-mode. User-mode issues typically involve things like applications running under QEMU, while system-mode deals with lower-level stuff like hardware emulation, device drivers, etc.
Epoll is a Linux API used for I/O multiplexing, which is part of the kernel's syscalls. In QEMU, when running in user-mode (like qemu-i386), it emulates the CPU and translates syscalls to the host's syscalls. If there's an issue with how QEMU handles epoll calls on an ARM host when running i386 code, that would be a user-mode problem because it's about translating system calls correctly.
The commit in question likely changed something in the syscall translation or handling for ARM hosts when emulating i386. So this is more about how user applications interact with QEMU rather than the virtualized hardware or kernel setup.
So I think this bug is related to user-mode.
</think>
user
|