1 files changed, 48 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/2669 b/results/classifier/118/graphic/2669
new file mode 100644
index 000000000..09654636b
--- /dev/null
+++ b/results/classifier/118/graphic/2669
@@ -0,0 +1,48 @@
+graphic: 0.871
+debug: 0.851
+device: 0.818
+architecture: 0.775
+virtual: 0.747
+vnc: 0.742
+semantic: 0.726
+hypervisor: 0.713
+performance: 0.683
+user-level: 0.681
+ppc: 0.677
+boot: 0.676
+kernel: 0.655
+register: 0.631
+mistranslation: 0.625
+permissions: 0.583
+VMM: 0.570
+socket: 0.557
+assembly: 0.524
+PID: 0.495
+network: 0.494
+KVM: 0.471
+risc-v: 0.435
+files: 0.434
+arm: 0.421
+x86: 0.396
+i386: 0.335
+peripherals: 0.318
+TCG: 0.277
+
+CPU Hotplug (Host Model) Causes the Windows VM to BSOD
+Description of problem:
+The QEMU runs on a host with the Intel(R) Xeon(R) CPU E3-1230 v6 CPU which supports Software Guard Extension (SGX). I start a VM with Windows Server 2019 inside and with `-cpu host,...`. When I attempts to hotplug additional CPU (when the VM is running), the OS issues a bug check 0x3e (`MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED`). The problem is that the newly hotplugged CPU is not evaluated as "equivalent enough" compared to the already present CPUs. I did some more digging and reverse engineering and it looks like the CPU being hotplugged has SGX turned off. This seems to be fixed when the VM reboots.
+
+I tried to disable SGX through `-cpu host,-sgx` which helps (the VM successfully accepts the hotplugged CPU), however, `+sgx` does not help (seems to have no effect on the CPU being hotplugged).
+
+My goal is to be able to hotplug CPUs even when the host CPU supports SGX.
+
+I tested with QEMU 8.0.0, 9.1.0, 9.1.1 and 9.1.50 (current master) but with no luck.
+Steps to reproduce:
+1. Create a simple Windows VM,
+2. start the VM,
+3. use `qpm-shell` to hotplug a CPU (https://www.qemu.org/docs/master/system/cpu-hotplug.html).
+
+I can provide you the VM as well but its image (QCOW2) has around 10G in size.
+
+Best regards
+Martin Dráb