public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: edk2-devel-groups-io <devel@edk2.groups.io>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Jordan Justen <jordan.l.justen@intel.com>
Subject: [PATCH v2 06/11] OvmfPkg/PlatformPei: assert there's no permanent PEI RAM at default SMBASE
Date: Wed, 29 Jan 2020 22:44:07 +0100	[thread overview]
Message-ID: <20200129214412.2361-7-lersek@redhat.com> (raw)
In-Reply-To: <20200129214412.2361-1-lersek@redhat.com>

The permanent PEI RAM that is published on the normal boot path starts
strictly above MEMFD_BASE_ADDRESS (8 MB -- see the FDF files), regardless
of whether PEI decompression will be necessary on S3 resume due to
SMM_REQUIRE. Therefore the normal boot permanent PEI RAM never overlaps
with the SMRAM at the default SMBASE (192 KB).

The S3 resume permanent PEI RAM is strictly above the normal boot one.
Therefore the no-overlap statement holds true on the S3 resume path as
well.

Assert the no-overlap condition commonly for both boot paths in
PublishPeiMemory().

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
---

Notes:
    v2:
    - trim Cc list
    - pick up Jiewen's R-b <https://edk2.groups.io/g/devel/message/48166>

 OvmfPkg/PlatformPei/MemDetect.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 2bc1c46dffc2..4879ee87b797 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -17,6 +17,7 @@ Module Name:
 #include <IndustryStandard/I440FxPiix4.h>
 #include <IndustryStandard/Q35MchIch9.h>
 #include <PiPei.h>
+#include <Register/Intel/SmramSaveStateMap.h>
 
 //
 // The Library classes this module consumes
@@ -626,6 +627,15 @@ PublishPeiMemory (
     }
   }
 
+  //
+  // MEMFD_BASE_ADDRESS separates the SMRAM at the default SMBASE from the
+  // normal boot permanent PEI RAM. Regarding the S3 boot path, the S3
+  // permanent PEI RAM is located even higher.
+  //
+  if (FeaturePcdGet (PcdSmmSmramRequire) && mQ35SmramAtDefaultSmbase) {
+    ASSERT (SMM_DEFAULT_SMBASE + MCH_DEFAULT_SMBASE_SIZE <= MemoryBase);
+  }
+
   //
   // Publish this memory to the PEI Core
   //
-- 
2.19.1.3.g30247aa5d201



  parent reply	other threads:[~2020-01-29 21:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-29 21:44 [PATCH v2 00/11] support QEMU's "SMRAM at default SMBASE" feature Laszlo Ersek
2020-01-29 21:44 ` [PATCH v2 01/11] OvmfPkg: introduce PcdQ35SmramAtDefaultSmbase Laszlo Ersek
2020-01-29 21:44 ` [PATCH v2 02/11] OvmfPkg/IndustryStandard: increase vertical whitespace in Q35 macro defs Laszlo Ersek
2020-01-29 21:44 ` [PATCH v2 03/11] OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register macros Laszlo Ersek
2020-01-29 21:44 ` [PATCH v2 04/11] OvmfPkg/PlatformPei: factor out Q35BoardVerification() Laszlo Ersek
2020-01-29 21:44 ` [PATCH v2 05/11] OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (skeleton) Laszlo Ersek
2020-01-29 21:44 ` Laszlo Ersek [this message]
2020-01-29 21:44 ` [PATCH v2 07/11] OvmfPkg/PlatformPei: reserve the SMRAM at the default SMBASE, if it exists Laszlo Ersek
2020-01-29 21:44 ` [PATCH v2 08/11] OvmfPkg/SEV: don't manage the lifecycle of the SMRAM at the default SMBASE Laszlo Ersek
2020-01-29 21:44 ` [PATCH v2 09/11] OvmfPkg/SmmAccess: close and lock SMRAM at " Laszlo Ersek
2020-01-29 21:44 ` [PATCH v2 10/11] OvmfPkg: introduce PcdCsmEnable feature flag Laszlo Ersek
2020-01-29 21:44 ` [PATCH v2 11/11] OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real) Laszlo Ersek
2020-02-05  0:22 ` [PATCH v2 00/11] support QEMU's "SMRAM at default SMBASE" feature Ard Biesheuvel
2020-02-05 13:44   ` [edk2-devel] " 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=20200129214412.2361-7-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