Hi,
I'm sending a new email about the latest status, because the thread
under the blurb
[edk2] [PATCH v3 00/52] OvmfPkg: support SMM for better security
(steps towards MP and X64)
http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020
has grown too large and fragmented.
Fresh environment and results:
* Host kernel:
- Upstream Linux "kvm/master", at ad355e383d82.
(This is v4.3-rc3 based.)
- Plus the following patch applied:
[PATCH] KVM: x86: fix RSM into 64-bit protected mode, round 2
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/141965
* QEMU:
- Current upstream "master", at bc79082e4cd1.
- Plus the following patch applied:
[PATCH] hw/isa/lpc_ich9: inject SMI on all VCPUs if APM_STS == 'Q'
http://thread.gmane.org/gmane.comp.emulators.qemu/371195
* edk2 / OVMF:
- The v3 series (see subject and link above) rebased upon SVN r18651
(git commit 0f34a051104e).
- The rebase obviates the following:
[PATCH v3 01/52] UefiCpuPkg: CpuDxe: Fix ASSERT() when only 1 CPU
detected
[PATCH v3 02/52] UefiCpuPkg: PiSmmCpuDxeSmm: prepare PT in InitPaging
before filling in PDE
[PATCH v3 04/52] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs
- Paolo's patch below remains necessary for the time being, but
ultimately it will be rendered unneeded by further KVM (i.e., host
kernel) changes:
[PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from
64-bit mode
- In addition, matching the QEMU patch referenced above,
[PATCH v3 27/52] OvmfPkg: use relaxed AP SMM synchronization mode
becomes unnecessary and is dropped, *and* the incremental OVMF patch
that I'm attaching now purely for illustration is squashed into
[PATCH v3 13/52] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a
DXE_RUNTIME_DRIVER
* QEMU command line options:
- The following are shared by *all* test cases:
-machine pc-q35-2.4,smm=on,accel=$ACCEL \
-global driver=cfi.pflash01,property=secure,value=on \
-smp cpus=2 \
-global ICH9-LPC.disable_s3=0 \
-global ICH9-LPC.disable_s4=1 \
-m 2048 \
(That is, *all* of the tests below use 2 VCPUs; the above is only
customized with $ACCEL.)
- The 32-bit tests are run with "qemu-system-i386", and
"-cpu coreduo,-nx" is added after the common options.
- The 64-bit tests are run with "qemu-system-x86_64", and
there are no special options.
* Results:
accel bits guest OS OS boots efibootmgr works on S3 resume
----- ---- --------------- -------- ------------------- ---------
TCG 32 Fedlet 20141209 pass[1] BSP and AP pass
TCG 64 F21 XFCE LiveCD pass[1] BSP and AP fail[2]
KVM 32 Fedlet 20141209 pass BSP and AP pass
KVM 64 F21 XFCE LiveCD pass BSP and AP fail[2]
KVM 64 Windows 8.1 pass n/a fail[2]
[1] Although the boot is successful, I'm seeing one worrying sign: it
looks like sometime after boot (when OVMF is "all done"), the AP
starts executing the firmware from flash (I can see the SEC messages
up to and including "DecompressMemFvs"). I don't understand why this
happens, but it doesn't seem right. In any case, it didn't break
these tests.
Although it should be clear from the above table, I'd like to
emphasize: this occurs only with TCG.
[2] In PiCpuSmmEntry(), PiSmmCpuDxeSmm runs
SmmS3ResumeState->Signature = SMM_S3_RESUME_SMM_64;
This causes S3RestoreConfig2() in S3Resume2Pei to call
AsmEnablePaging64() during S3 resume. However, that function doesn't
work on X64: it calls InternalX86EnablePaging64(), and the X64
implementation for *that* is "ASSERT (FALSE)". See
"MdePkg/Library/BaseLib/X64/Non-existing.c".
I don't understand how the SMM_S3_RESUME_SMM_64 branch in
S3RestoreConfig2() is supposed to work at all.
* TODO:
- celebrate a bit this weekend (look at that "OS boots" column!)
- figure out what we want wrt. the QEMU patch
- track down [1]
- ask for help with [2] -- no clue
- post v4 for OVMF and start poking people in earnest for the missing
reviews :)
- celebrate some more?
Thanks
Laszlo
From 0145e57f279238f876d5dfe61cc0f5dc827d416d Mon Sep 17 00:00:00 2001
From: Laszlo Ersek <[email protected]>
Date: Fri, 23 Oct 2015 17:10:38 +0200
Subject: [PATCH] (SQUASH) OvmfPkg: SmmControl2Dxe: select broadcast SMI
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <[email protected]>
---
Notes:
v4:
- select broadcast SMI in Trigger()
OvmfPkg/Include/IndustryStandard/Q35MchIch9.h | 6 ++++--
OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c | 12 +++++++++++-
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
index 18b34a3..3fa2639 100644
--- a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
+++ b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h
@@ -83,8 +83,10 @@
//
// IO ports
//
-#define ICH9_APM_CNT 0xB2
-#define ICH9_APM_STS 0xB3
+#define ICH9_APM_CNT 0xB2
+
+#define ICH9_APM_STS 0xB3
+#define QEMU_ICH9_APM_STS_BROADCAST_SMI 'Q'
//
// IO ports relative to PMBASE
diff --git a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c
index e895fd6..4f60ca4 100644
--- a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c
+++ b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c
@@ -95,10 +95,20 @@ SmmControl2DxeTrigger (
// report about hardware status, while this register is fully governed by
// software.
//
+ // On the QEMU platform, we use the status register to request a "broadcast"
+ // SMI; i.e., to bring all VCPUs into SMM at once. Edk2 handles the case when
+ // the SMI is raised only on the processor that calls Trigger(), but that
+ // case has much worse performance.
+ //
+ // Note that we exploit the fact that the SMM_CORE never passes a non-NULL
+ // DataPort pointer (that is, we exploit that it doesn't care about the
+ // status register value).
+ //
// Write to the status register first, as this won't trigger the SMI just
// yet. Then write to the control register.
//
- IoWrite8 (ICH9_APM_STS, DataPort == NULL ? 0 : *DataPort);
+ ASSERT (DataPort == NULL);
+ IoWrite8 (ICH9_APM_STS, QEMU_ICH9_APM_STS_BROADCAST_SMI);
IoWrite8 (ICH9_APM_CNT, CommandPort == NULL ? 0 : *CommandPort);
return EFI_SUCCESS;
}
--
1.8.3.1
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
