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 --- results/classifier/deepseek-2-tmp/reasoning/hypervisor/2981 | 13 ------------- 1 file changed, 13 deletions(-) delete mode 100644 results/classifier/deepseek-2-tmp/reasoning/hypervisor/2981 (limited to 'results/classifier/deepseek-2-tmp/reasoning/hypervisor/2981') diff --git a/results/classifier/deepseek-2-tmp/reasoning/hypervisor/2981 b/results/classifier/deepseek-2-tmp/reasoning/hypervisor/2981 deleted file mode 100644 index 7b444d9a..00000000 --- a/results/classifier/deepseek-2-tmp/reasoning/hypervisor/2981 +++ /dev/null @@ -1,13 +0,0 @@ - -Okay, so I have this bug report about QEMU and I need to classify it into one of the given categories. Let's see what the problem is. - -The user tried running QEMU with `-machine virt,accel=hvf:tcg` on a Mac OS guest and host, both arm64. They expected that since HVF (which is Heterogeneous Virtualization Framework) isn't supported due to nested virtualization not being available, it would fall back to TCG (Translation-Cache Generator). But instead, QEMU crashes. - -Looking at the error message: `qemu-system-aarch64: Error: ret = HV_UNSUPPORTED (0xfae9400f, at ../target/arm/hvf/hvf.c:949)`. This indicates that when trying to use HVF, it's returning an unsupported error. The stack trace shows functions related to HVF acceleration initialization and assertion handling. - -The user also mentions that this works fine with KVM but fails with HVF, which points towards an issue specific to the hypervisor or virtualization layer on macOS. Since QEMU is attempting to use HVF first and crashing because it's unsupported, the fallback to TCG isn't happening as intended. - -Looking at the categories: The problem involves the acceleration mechanism (HVF) in QEMU, which relates to the hypervisor support. So the category should be "hypervisor". - - -hypervisor \ No newline at end of file -- cgit 1.4.1