semantic: 0.152
other: 0.143
debug: 0.134
device: 0.127
boot: 0.072
performance: 0.064
PID: 0.051
socket: 0.046
files: 0.045
graphic: 0.044
vnc: 0.036
permissions: 0.036
network: 0.026
KVM: 0.025
KVM: 0.292
debug: 0.220
performance: 0.126
files: 0.072
other: 0.063
PID: 0.063
boot: 0.039
socket: 0.026
device: 0.023
semantic: 0.023
network: 0.020
graphic: 0.013
permissions: 0.011
vnc: 0.010

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.