From: "Laszlo Ersek" <lersek@redhat.com>
To: edk2-devel-groups-io <devel@edk2.groups.io>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Igor Mammedov <imammedo@redhat.com>,
Jiewen Yao <jiewen.yao@intel.com>,
Joao M Martins <joao.m.martins@oracle.com>,
Jordan Justen <jordan.l.justen@intel.com>,
Jun Nakajima <jun.nakajima@intel.com>,
Michael Kinney <michael.d.kinney@intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Phillip Goerl <phillip.goerl@oracle.com>,
Yingwen Chen <yingwen.chen@intel.com>
Subject: [PATCH wave 1 09/10] OvmfPkg/SmmAccess: close and lock SMRAM at default SMBASE
Date: Tue, 24 Sep 2019 13:35:04 +0200 [thread overview]
Message-ID: <20190924113505.27272-10-lersek@redhat.com> (raw)
In-Reply-To: <20190924113505.27272-1-lersek@redhat.com>
During normal boot, when EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed
by platform BDS, the SMM IPL locks SMRAM (TSEG) through
EFI_SMM_ACCESS2_PROTOCOL.Lock(). See SmmIplReadyToLockEventNotify() in
"MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c".
During S3 resume, S3Resume2Pei locks SMRAM (TSEG) through
PEI_SMM_ACCESS_PPI.Lock(), before executing the boot script. See
S3ResumeExecuteBootScript() in
"UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c".
Those are precisely the places where the SMRAM at the default SMBASE
should be locked too. Add such an action to SmramAccessLock().
Notes:
- The SMRAM at the default SMBASE doesn't support the "closed and
unlocked" state (and so it can't be closed without locking it, and it
cannot be opened after closing it).
- The SMRAM at the default SMBASE isn't (and shouldn't) be exposed with
another EFI_SMRAM_DESCRIPTOR in the GetCapabilities() members of
EFI_SMM_ACCESS2_PROTOCOL / PEI_SMM_ACCESS_PPI. That's because the SMRAM
in question is not "general purpose"; it's only QEMU's solution to
protect the initial SMI handler from the OS, when a VCPU is hot-plugged.
Consequently, the state of the SMRAM at the default SMBASE is not
reflected in the "OpenState" / "LockState" fields of the protocol and
PPI.
- An alternative to extending SmramAccessLock() would be to register an
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL notify in SmmAccess2Dxe (for locking
at normal boot), and an EDKII_S3_SMM_INIT_DONE_GUID PPI notify in
SmmAccessPei (for locking at S3 resume).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Joao M Martins <joao.m.martins@oracle.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Jun Nakajima <jun.nakajima@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Phillip Goerl <phillip.goerl@oracle.com>
Cc: Yingwen Chen <yingwen.chen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
OvmfPkg/SmmAccess/SmmAccess2Dxe.inf | 1 +
OvmfPkg/SmmAccess/SmmAccessPei.inf | 1 +
OvmfPkg/SmmAccess/SmramInternal.h | 8 +++++++
OvmfPkg/SmmAccess/SmmAccess2Dxe.c | 7 ++++++
OvmfPkg/SmmAccess/SmmAccessPei.c | 6 +++++
OvmfPkg/SmmAccess/SmramInternal.c | 25 ++++++++++++++++++++
6 files changed, 48 insertions(+)
diff --git a/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf b/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
index 7ced6b4e7ff4..d86381d0fbe2 100644
--- a/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+++ b/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
@@ -49,6 +49,7 @@ [FeaturePcd]
gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
[Pcd]
+ gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase
gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
[Depex]
diff --git a/OvmfPkg/SmmAccess/SmmAccessPei.inf b/OvmfPkg/SmmAccess/SmmAccessPei.inf
index d73a029cc790..1698c4ce6c92 100644
--- a/OvmfPkg/SmmAccess/SmmAccessPei.inf
+++ b/OvmfPkg/SmmAccess/SmmAccessPei.inf
@@ -54,6 +54,7 @@ [FeaturePcd]
gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
[Pcd]
+ gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase
gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
[Ppis]
diff --git a/OvmfPkg/SmmAccess/SmramInternal.h b/OvmfPkg/SmmAccess/SmramInternal.h
index 74d962b4ecae..a4d8827adfe4 100644
--- a/OvmfPkg/SmmAccess/SmramInternal.h
+++ b/OvmfPkg/SmmAccess/SmramInternal.h
@@ -38,6 +38,14 @@ InitQ35TsegMbytes (
VOID
);
+/**
+ Save PcdQ35SmramAtDefaultSmbase into mQ35SmramAtDefaultSmbase.
+**/
+VOID
+InitQ35SmramAtDefaultSmbase (
+ VOID
+ );
+
/**
Read the MCH_SMRAM and ESMRAMC registers, and update the LockState and
OpenState fields in the PEI_SMM_ACCESS_PPI / EFI_SMM_ACCESS2_PROTOCOL object,
diff --git a/OvmfPkg/SmmAccess/SmmAccess2Dxe.c b/OvmfPkg/SmmAccess/SmmAccess2Dxe.c
index e098f6f15f77..3691a6cd1f10 100644
--- a/OvmfPkg/SmmAccess/SmmAccess2Dxe.c
+++ b/OvmfPkg/SmmAccess/SmmAccess2Dxe.c
@@ -145,6 +145,13 @@ SmmAccess2DxeEntryPoint (
InitQ35TsegMbytes ();
GetStates (&mAccess2.LockState, &mAccess2.OpenState);
+
+ //
+ // SmramAccessLock() depends on "mQ35SmramAtDefaultSmbase"; init the latter
+ // just before exposing the former via EFI_SMM_ACCESS2_PROTOCOL.Lock().
+ //
+ InitQ35SmramAtDefaultSmbase ();
+
return gBS->InstallMultipleProtocolInterfaces (&ImageHandle,
&gEfiSmmAccess2ProtocolGuid, &mAccess2,
NULL);
diff --git a/OvmfPkg/SmmAccess/SmmAccessPei.c b/OvmfPkg/SmmAccess/SmmAccessPei.c
index d67850651c58..c8bbc17e907a 100644
--- a/OvmfPkg/SmmAccess/SmmAccessPei.c
+++ b/OvmfPkg/SmmAccess/SmmAccessPei.c
@@ -372,6 +372,12 @@ SmmAccessPeiEntryPoint (
CopyMem (GuidHob, &SmramMap[DescIdxSmmS3ResumeState],
sizeof SmramMap[DescIdxSmmS3ResumeState]);
+ //
+ // SmramAccessLock() depends on "mQ35SmramAtDefaultSmbase"; init the latter
+ // just before exposing the former via PEI_SMM_ACCESS_PPI.Lock().
+ //
+ InitQ35SmramAtDefaultSmbase ();
+
//
// We're done. The next step should succeed, but even if it fails, we can't
// roll back the above BuildGuidHob() allocation, because PEI doesn't support
diff --git a/OvmfPkg/SmmAccess/SmramInternal.c b/OvmfPkg/SmmAccess/SmramInternal.c
index 09657d0f9b0f..0b07dc667b3f 100644
--- a/OvmfPkg/SmmAccess/SmramInternal.c
+++ b/OvmfPkg/SmmAccess/SmramInternal.c
@@ -21,6 +21,12 @@
//
UINT16 mQ35TsegMbytes;
+//
+// The value of PcdQ35SmramAtDefaultSmbase is saved into this variable at
+// module startup.
+//
+STATIC BOOLEAN mQ35SmramAtDefaultSmbase;
+
/**
Save PcdQ35TsegMbytes into mQ35TsegMbytes.
**/
@@ -32,6 +38,17 @@ InitQ35TsegMbytes (
mQ35TsegMbytes = PcdGet16 (PcdQ35TsegMbytes);
}
+/**
+ Save PcdQ35SmramAtDefaultSmbase into mQ35SmramAtDefaultSmbase.
+**/
+VOID
+InitQ35SmramAtDefaultSmbase (
+ VOID
+ )
+{
+ mQ35SmramAtDefaultSmbase = PcdGetBool (PcdQ35SmramAtDefaultSmbase);
+}
+
/**
Read the MCH_SMRAM and ESMRAMC registers, and update the LockState and
OpenState fields in the PEI_SMM_ACCESS_PPI / EFI_SMM_ACCESS2_PROTOCOL object,
@@ -125,6 +142,14 @@ SmramAccessLock (
PciOr8 (DRAMC_REGISTER_Q35 (MCH_ESMRAMC), MCH_ESMRAMC_T_EN);
PciOr8 (DRAMC_REGISTER_Q35 (MCH_SMRAM), MCH_SMRAM_D_LCK);
+ //
+ // Close & lock the SMRAM at the default SMBASE, if it exists.
+ //
+ if (mQ35SmramAtDefaultSmbase) {
+ PciWrite8 (DRAMC_REGISTER_Q35 (MCH_DEFAULT_SMBASE_CTL),
+ MCH_DEFAULT_SMBASE_LCK);
+ }
+
GetStates (LockState, OpenState);
if (*OpenState || !*LockState) {
return EFI_DEVICE_ERROR;
--
2.19.1.3.g30247aa5d201
next prev parent reply other threads:[~2019-09-24 11:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-24 11:34 [PATCH wave 1 00/10] support QEMU's "SMRAM at default SMBASE" feature Laszlo Ersek
2019-09-24 11:34 ` [PATCH wave 1 01/10] OvmfPkg: introduce PcdQ35SmramAtDefaultSmbase Laszlo Ersek
2019-09-24 11:34 ` [PATCH wave 1 02/10] OvmfPkg/IndustryStandard: increase vertical whitespace in Q35 macro defs Laszlo Ersek
2019-09-24 11:44 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-24 11:34 ` [PATCH wave 1 03/10] OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register macros Laszlo Ersek
2019-09-24 11:34 ` [PATCH wave 1 04/10] OvmfPkg/PlatformPei: factor out Q35BoardVerification() Laszlo Ersek
2019-09-24 11:41 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-24 11:35 ` [PATCH wave 1 05/10] OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (skeleton) Laszlo Ersek
2019-09-24 11:35 ` [PATCH wave 1 06/10] OvmfPkg/PlatformPei: assert there's no permanent PEI RAM at default SMBASE Laszlo Ersek
2019-09-24 11:35 ` [PATCH wave 1 07/10] OvmfPkg/PlatformPei: reserve the SMRAM at the default SMBASE, if it exists Laszlo Ersek
2019-09-24 11:35 ` [PATCH wave 1 08/10] OvmfPkg/SEV: don't manage the lifecycle of the SMRAM at the default SMBASE Laszlo Ersek
2019-09-24 11:35 ` Laszlo Ersek [this message]
2019-09-24 11:35 ` [PATCH wave 1 10/10] OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real) Laszlo Ersek
2019-09-26 8:46 ` [edk2-devel] [PATCH wave 1 00/10] support QEMU's "SMRAM at default SMBASE" feature Yao, Jiewen
2019-09-26 14:51 ` Laszlo Ersek
2019-09-27 1:14 ` Yao, Jiewen
2019-10-01 14:43 ` Laszlo Ersek
2019-09-27 11:35 ` Igor Mammedov
2019-10-01 15:31 ` Laszlo Ersek
2019-10-04 14:09 ` Igor Mammedov
2019-10-07 9:34 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190924113505.27272-10-lersek@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox