blob: 8dd383cb208b3e709aaf815a5ed7e765dc8d6bec (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Alright, so I'm trying to figure out how to classify this bug report about QEMU. Let me start by reading the problem description carefully.
The user reports that when running a specific QEMU setup with HVF acceleration, the RDTSCP capability isn't being passed to the guest OS. They provided steps to reproduce: using an Alpine Linux ISO and specifying the CPU with +rdtscp. After booting, they check for the rdtscp flag in /etc/cpuinfo but find it missing, along with a warning that the host doesn't support the feature.
Looking at QEMU's components, HVF is Apple's hypervisor on macOS. The issue seems related to how CPU features are exposed to the guest. Since RDTSCP is a CPU instruction, this likely involves how QEMU translates or passes these features through the hypervisor.
The possible categories include things like 'hypervisor', which makes sense because HVF is a hypervisor component. Other options like 'assembly' or 'mistranslation' might be involved in how instructions are handled, but the primary issue here is about feature exposure via the hypervisor layer.
The patch link suggests it's a known issue that was addressed, likely by modifying how QEMU/HVF handles CPU features. So this falls under hypervisor-related bugs rather than something like network or performance issues.
</think>
hypervisor
|