diff options
Diffstat (limited to 'results/classifier/gemma3:12b/kernel/2064')
| -rw-r--r-- | results/classifier/gemma3:12b/kernel/2064 | 13 |
1 files changed, 13 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/kernel/2064 b/results/classifier/gemma3:12b/kernel/2064 new file mode 100644 index 00000000..a277056f --- /dev/null +++ b/results/classifier/gemma3:12b/kernel/2064 @@ -0,0 +1,13 @@ + +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. |