From 25f8033d556aa17afaea4a5196ea7a69fe248320 Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Mon, 30 Jun 2025 12:34:26 +0000 Subject: add new temporary deepseek-r1:14b results --- results/classifier/deepseek-2-tmp/reasoning/hypervisor/2981 | 13 +++++++++++++ 1 file changed, 13 insertions(+) create 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 new file mode 100644 index 00000000..7b444d9a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/reasoning/hypervisor/2981 @@ -0,0 +1,13 @@ + +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 v1.2.3