blob: 8fc820b2d99ef0b704753eda11d9ae9ac3d57797 (
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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
x86: 0.949
architecture: 0.706
semantic: 0.619
device: 0.610
performance: 0.596
graphic: 0.580
files: 0.523
peripherals: 0.492
socket: 0.490
ppc: 0.488
kernel: 0.458
hypervisor: 0.456
mistranslation: 0.448
permissions: 0.444
register: 0.434
debug: 0.428
i386: 0.419
risc-v: 0.416
network: 0.376
vnc: 0.375
assembly: 0.368
TCG: 0.361
PID: 0.347
VMM: 0.307
user-level: 0.306
boot: 0.298
virtual: 0.289
arm: 0.209
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.
|