From d0c85e36e4de67af628d54e9ab577cc3fad7796a Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Thu, 3 Jul 2025 07:27:52 +0000 Subject: add deepseek and gemma results --- .../classifier/deepseek-2-tmp/reasoning/hypervisor/1864536 | 11 ----------- 1 file changed, 11 deletions(-) delete mode 100644 results/classifier/deepseek-2-tmp/reasoning/hypervisor/1864536 (limited to 'results/classifier/deepseek-2-tmp/reasoning/hypervisor/1864536') diff --git a/results/classifier/deepseek-2-tmp/reasoning/hypervisor/1864536 b/results/classifier/deepseek-2-tmp/reasoning/hypervisor/1864536 deleted file mode 100644 index 9c1e5bdf..00000000 --- a/results/classifier/deepseek-2-tmp/reasoning/hypervisor/1864536 +++ /dev/null @@ -1,11 +0,0 @@ - -Alright, let's figure out which category this bug report falls into. The user is talking about issues with XSAVES instructions in QEMU when using Hyper-V on KVM. They mentioned that during initialization, Hyper-V checks for XSAVES support via CPUID and MSR flags. - -The problem arises because QEMU isn't correctly handling these features. Specifically, the XSAVES feature isn't added to the FEAT_VMX_SECONDARY_CTLS in target/i386/cpu.c, which causes KVM to mask off the feature. This leads Hyper-V to fail its initialization. - -Looking at the provided categories: device, graphic, socket, network, KVM, etc., I need to determine where this issue fits. The bug is related to how QEMU handles CPU features and MSR settings for KVM virtualization. It's about incorrect mapping from the host's CPU features (like XSAVES) into the target VM configuration in QEMU/KVM. - -Since the problem involves handling of specific CPU instructions and their support in the hypervisor (KVM), this relates more to how the hypervisor interacts with the hardware features through QEMU. Therefore, it falls under the 'hypervisor' category because the issue is about the interaction between KVM and QEMU regarding CPU feature flags. - - -hypervisor \ No newline at end of file -- cgit 1.4.1