1 files changed, 68 insertions, 0 deletions
diff --git a/results/classifier/118/none/1888971 b/results/classifier/118/none/1888971
new file mode 100644
index 000000000..ac75f355d
--- /dev/null
+++ b/results/classifier/118/none/1888971
@@ -0,0 +1,68 @@
+x86: 0.795
+device: 0.587
+debug: 0.583
+architecture: 0.564
+mistranslation: 0.427
+semantic: 0.372
+performance: 0.369
+ppc: 0.357
+graphic: 0.294
+boot: 0.288
+virtual: 0.246
+i386: 0.245
+user-level: 0.240
+socket: 0.229
+PID: 0.221
+register: 0.211
+kernel: 0.205
+hypervisor: 0.166
+risc-v: 0.164
+permissions: 0.161
+vnc: 0.144
+arm: 0.140
+network: 0.124
+files: 0.122
+peripherals: 0.111
+VMM: 0.090
+TCG: 0.083
+assembly: 0.078
+KVM: 0.072
+
+SMI trigger causes hang with multiple cores
+
+When using qemu , SMI trigger causes hand/reboot under following conditions:
+
+1. No KVM but there are more than 1 threads (-smp > 1)
+2. When using KVM.
+
+Info:
+qemu-system-x86_64 --version
+QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.29)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+SMI trigger was done by writing 0x00 in IO port 0xB2.
+
+Does coreboot do anything to set up an SMI handler? Does it relocate SMBASE for all processors?
+
+Misbehavior upon raising an SMI is fully expected, unless the guest (usually the guest firmware) sets up SMI handling properly.
+
+The bug report currently includes only two bits of information about guest actions, namely "coreboot.rom" and "writing 0x00 in IO port 0xB2". Thus far a guest crash looks entirely reasonable to me.
+
+Did you intend to attach "1.txt"?
+
+I tried without specifying -bios parameter still hang is seen. But this time it had low memory corruption.
+
+And built seabios with more debug logs but seabios doesn't does SMM init even when its selected in make menuconfig.
+
+I guess fundamentally th issue is writing 0xXX in IO port 0xB2 should trigger SMI handler in all possible core but instead it triggers SMI only in Core#0.
+
+> I guess fundamentally th issue is writing 0xXX in IO port 0xB2 should
+> trigger SMI handler in all possible core but instead it triggers SMI
+> only in Core#0.
+
+For that, the guest needs to negotiate the "broadcast SMI" feature with
+QEMU. See commit range 57bb40c9db40..b8bab8eb6934.
+
+
+Inactive for ~two weeks, closing.
+