blob: 6b05a4bb67334778b3e1f8334aeacbde60305ef5 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I need to classify this bug report into one of the given categories for QEMU. Let's start by reading the problem carefully.
The user is reporting that QEMU/KVM locks up when running a 32-bit userspace with a 64-bit kernel on x86 systems. They mention it happens with both QEMU and QEMU-KVM version 1.0, but not in older versions like 0.15. The issue occurs specifically when the kernel is 64-bit and the userspace is 32-bit. It doesn't happen for all guests, but a particular case with a 32-bit Windows 7 guest consistently causes the problem.
When this happens, Windows detects a new CPU and prompts to reboot. After hitting "Reboot," the system locks up with 100% CPU usage, making it unresponsive except for being killable via -9.
Now, looking at the possible categories: mistranslation relates to incorrect mapping from source to target architecture, which could be relevant here since it's a mix of 32-bit and 64-bit environments. But I'm not sure if that's the exact issue. Alternatively, KVM is involved because the problem occurs with QEMU-KVM.
The bug report points towards an interaction between the 32-bit guest OS (Windows 7) and the 64-bit host kernel in QEMU/KVM. This seems like a hypervisor-related issue since KVM is a hypervisor that allows running guests under the host OS. Therefore, the problem might be in how KVM/QEMU handles the combination of 32-bit userspace on a 64-bit kernel.
So, considering the categories, "KVM" seems to fit because it's specifically about the hypervisor component causing the lock-up when certain configurations are used. The issue isn't related to assembly or translation errors but rather to how KVM manages the virtual environment.
</think>
The bug report describes a problem where QEMU/KVM locks up when running a 32-bit userspace with a 64-bit kernel. This is specific to the hypervisor component, so the category is:
KVM
|