1 files changed, 27 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/kvm/1864536 b/results/classifier/gemma3:12b/kvm/1864536
new file mode 100644
index 00000000..7dea9ba3
--- /dev/null
+++ b/results/classifier/gemma3:12b/kvm/1864536
@@ -0,0 +1,27 @@
+
+Support for XSAVES intel instructions in QEMU
+
+Dear QEMU developers,
+
+I am running Hyper-V on qemu+kvm. During it initialization, it checks for XSAVES support: first it executes CPUID with EAX = 0xd and ECX = 1 and looks at bit 3 in the returned value of EAX (Supports XSAVES/XRSTORS and IA32_XSS [1]), and then it reads the MSR IA32_VMX_PROCBASED_CTLS2 (index 0x48B) and looks at bit 20 (Enable XSAVES/XSTORS [2]). If CPUID shows that XSAVES is supported and the bit is not enabled in the MSR, Hyper-V decides to fail and stops its initialization. It used to work until last spring/summer where something might have changed in either KVM or QEMU.
+
+It seems that KVM sets the correct flags (in CPUID and the MSR) when the host CPU supports XSAVES. In QEMU, based on comments in target/i386/cpu.c it seems that XSAVES is not added in
+builtin_x86_defs[].features[FEAT_VMX_SECONDARY_CTLS] because it might break live migration. Therefore, when setting the MSR for the vcpu, QEMU is masking off the feature.
+
+I have tested two possible solutions:
+- adding the flag in .features[FEAT_VMX_SECONDARY_CTLS]
+- removing the support of the instruction in feature_word_info[FEAT_XSAVE].feat_names
+
+Both solutions work and Hyper-v is happily running. I can provide a patch for the solution you might consider applying. Otherwise, is there a better way to fix the issue?
+
+Qemu version: 4.2.0
+Kernel version: 5.5.4
+Qemu command: https://gist.github.com/0xabe-io/b4d797538e2160252addc1d1d64738e2
+
+
+Many thanks,
+Alexandre
+
+Ref:
+[1] Intel SDM Volume 2A, chapter 3, page 196
+[2] Intel SDM Volume 3C, chapter 24, page 11
\ No newline at end of file