1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Alright, let's figure out which category this bug report falls into. The user is reporting that when using QEMU with the "host-passthrough" option for a VM, the microcode version inside the VM remains at 0x1, even though the host has a higher microcode version (0x3d). They mentioned that they're running an ESXi nested VM which requires at least microcode version 0x19.
The issue seems to be related to how QEMU handles CPU microcode when using KVM acceleration with host-passthrough. The user expects the VM to inherit the host's microcode, but it's not happening. So, I need to determine the category based on the provided options: mistranslation, assembly, device, etc.
Looking at the list, "mistranslation" refers to incorrect mapping from source to target architecture in user-mode. This doesn't seem directly related here. The problem is about microcode versioning, which is a CPU-specific feature, so it's more about how the hypervisor (QEMU/KVM) presents the CPU information to the guest.
The other possible category is "hypervisor" since QEMU acts as a hypervisor when running KVM. Alternatively, it could be under "cpu" or something similar, but that's not in the list. Since the user is using host-passthrough and the issue relates to how microcode is handled by the VM's CPU configuration, it points towards an issue within the hypervisor layer.
Therefore, the category should be "hypervisor."
</think>
The bug report discusses how QEMU doesn't correctly pass the host's microcode version to the guest when using host-passthrough. This relates to how the hypervisor (QEMU/KVM) configures and presents CPU information to the virtual machine.
**Answer:** hypervisor
|