blob: 294752d8a033535ebfe1360036947f026d9e0ac5 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
semantic: 0.619
device: 0.610
graphic: 0.580
instruction: 0.519
socket: 0.490
other: 0.489
mistranslation: 0.448
network: 0.376
vnc: 0.375
assembly: 0.368
boot: 0.298
KVM: 0.203
QEMU v8.2.0-rc4 and above will not take SMI
Description of problem:
Starting from v8.2.0-rc4, the x86 QEMU system will take SMI from an incorrect starting address. Without any firmware relocation, sending an SMI will move the RIP to 0x8000, instead of the traditional 0x38000. This caused the existing UEFI drivers not functional during SMI relocation step.
After some investigation, the issue was caused by this commit: https://github.com/qemu/qemu/commit/b5e0d5d22fbffc3d8f7d3e86d7a2d05a1a974e27. There seems to be 2 issues with this change:
1. This code section https://github.com/qemu/qemu/blob/7425b6277f12e82952cede1f531bfc689bf77fb1/target/i386/tcg/translate.c#L568C1-L572C6 was updated from calculating `cpu_eip` based on `s->pc` to `s->base.pc_next`. This will cause undetermined behavior.
2. This code section https://github.com/qemu/qemu/blob/7425b6277f12e82952cede1f531bfc689bf77fb1/target/i386/tcg/translate.c#L2848C1-L2869C67 added the routine of updating `new_pc`, which is later used `tcg_gen_addi_tl`. This will cause the `new_pc` to be populated with undesirable value and thus cause faulting behaviors.
Steps to reproduce:
1. Launch once booting UEFI firmware, and the system will get stuck at the SMM base relocation logic.
Additional information:
I verified that after fixing the 2 issues mentioned above, the SMI can be correctly invoked at desired location.
|