1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
<think>
Okay, so I'm trying to figure out how to classify this bug report for QEMU. The user mentioned that after upgrading from Ubuntu 18.04 to 20.04, nested virtualization isn't working anymore with QEMU version 4.2. They were using the host CPU model and certain Hyper-V parameters in their command line.
First, I need to understand what's happening here. Nested hypervisors refer to running a hypervisor inside another hypervisor. In this case, the user is trying to run Windows 10 with Hyper-V enabled as the guest OS on top of QEMU/KVM. Before version 4.2, it worked fine, but now it's causing boot loops.
Looking at the provided information, the issue arises specifically when using the host CPU model (-cpu host) in QEMU 4.2 and newer. However, switching to a named CPU model like Skylake-Client-noTSX-IBRS allows the VM to boot, albeit with some issues later on. This suggests that there's a problem with how the host CPU model is being handled when nested hypervisors are involved.
The user also pointed out a specific commit in QEMU related to this issue: https://github.com/qemu/qemu/commit/20a78b02d31534ae478779c2f2816c273601e869. I can't check the commit directly, but knowing that it's from 4.2 suggests it might be a change in how QEMU handles certain CPU features or virtualization flags.
The categories provided include things like mistranslation, assembly lowering, and others like device, graphic, network, KVM, etc. The problem seems related to the hypervisor itself since it's about nested virtualization with Hyper-V. But I need to be precise.
Nested hypervisors typically rely on specific CPU features like VMX (Intel) or SVM (AMD). If QEMU is incorrectly handling these features when using the host CPU model, it could prevent the nested hypervisor from initializing properly, leading to boot loops.
Looking at the possible categories:
- **hypervisor**: This seems directly related since the issue is with running a hypervisor inside another.
- **KVM**: Since KVM is QEMU's hypervisor component, but the category "hypervisor" might be more specific here.
- **cpu**: Maybe, but the problem isn't the CPU itself but how QEMU handles it in nested mode.
The user also mentioned that using a named CPU model works around the issue, which points to a configuration or handling problem rather than a hardware issue. This suggests it's related to how QEMU configures the virtual CPU for nested hypervisors, possibly under the "hypervisor" category.
So, considering all this, the most appropriate category is **hypervisor**.
</think>
hypervisor
|