From: Laszlo Ersek <lersek@redhat.com>
To: edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Anthony Perard <anthony.perard@citrix.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Gary Ching-Pang Lin <glin@suse.com>,
Jordan Justen <jordan.l.justen@intel.com>,
Julien Grall <julien.grall@linaro.org>
Subject: [PATCH 2/4] OvmfPkg/EmuVariableFvbRuntimeDxe: stop using PcdVariableStoreSize
Date: Wed, 28 Mar 2018 22:26:49 +0200 [thread overview]
Message-ID: <20180328202651.1478-3-lersek@redhat.com> (raw)
In-Reply-To: <20180328202651.1478-1-lersek@redhat.com>
In commit 62f43f7c1947c, we set PcdVariableStoreSize to the same value as
PcdFlashNvStorageVariableSize (which in turn comes from VARS_LIVE_SIZE in
"OvmfPkg.fdf.inc").
This equality between both PCDs is a false requirement from
EmuVariableFvbRuntimeDxe. FVB drivers should use
PcdFlashNvStorageVariableSize for supporting non-volatile variables (even
if they happen to be kept in RAM only), along the other PcdFlashNvStorage*
PCDs. Whereas PcdVariableStoreSize is for variables that are volatile at
the gRT->SetVariable() / gRT->GetVariable() API level.
(PlatformPei too bases the preallocation for EmuVariableFvbRuntimeDxe on
PcdFlashNvStorageFtwSpareSize.)
Replace PcdVariableStoreSize in EmuVariableFvbRuntimeDxe with the
same-value PcdFlashNvStorageVariableSize. This means no change in
behavior, and it allows us to increase PcdVariableStoreSize in a later
patch without disturbing EmuVariableFvbRuntimeDxe (or PlatformPei).
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf | 3 +--
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c | 6 +++---
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
index 9f37938408a4..2aacf06c923d 100644
--- a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
+++ b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
@@ -58,12 +58,11 @@ [Protocols]
gEfiDevicePathProtocolGuid # PROTOCOL ALWAYS_PRODUCED
[FixedPcd]
- gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
[Pcd]
- gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase
diff --git a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
index 2d106bb50bed..9480d879c935 100644
--- a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
+++ b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
@@ -665,7 +665,7 @@ InitializeFvAndVariableStoreHeaders (
// UINT32 Size;
(
- FixedPcdGet32 (PcdVariableStoreSize) -
+ FixedPcdGet32 (PcdFlashNvStorageVariableSize) -
OFFSET_OF (FVB_FV_HDR_AND_VARS_TEMPLATE, VarHdr)
),
@@ -733,7 +733,7 @@ FvbInitialize (
ASSERT (FixedPcdGet32 (PcdFlashNvStorageFtwSpareSize) %
EMU_FVB_BLOCK_SIZE == 0);
if (
- (PcdGet32 (PcdVariableStoreSize) +
+ (PcdGet32 (PcdFlashNvStorageVariableSize) +
PcdGet32 (PcdFlashNvStorageFtwWorkingSize)
) >
EMU_FVB_NUM_SPARE_BLOCKS * EMU_FVB_BLOCK_SIZE
@@ -788,7 +788,7 @@ FvbInitialize (
//
// Initialize the Fault Tolerant Write data area
//
- SubPtr = (VOID*) ((UINT8*) Ptr + PcdGet32 (PcdVariableStoreSize));
+ SubPtr = (VOID*) ((UINT8*) Ptr + PcdGet32 (PcdFlashNvStorageVariableSize));
PcdStatus = PcdSet32S (PcdFlashNvStorageFtwWorkingBase,
(UINT32)(UINTN) SubPtr);
ASSERT_RETURN_ERROR (PcdStatus);
--
2.14.1.3.gb7cf6e02401b
next prev parent reply other threads:[~2018-03-28 20:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-28 20:26 [PATCH 0/4] MdeModulePkg, OvmfPkg: support large CA cert list for HTTPS boot Laszlo Ersek
2018-03-28 20:26 ` [PATCH 1/4] MdeModulePkg/Variable/RuntimeDxe: introduce PcdMaxVolatileVariableSize Laszlo Ersek
2018-03-29 1:34 ` Zeng, Star
2018-03-29 12:19 ` Laszlo Ersek
2018-03-30 0:54 ` Zeng, Star
2018-03-28 20:26 ` Laszlo Ersek [this message]
2018-03-30 10:57 ` [PATCH 2/4] OvmfPkg/EmuVariableFvbRuntimeDxe: stop using PcdVariableStoreSize Ard Biesheuvel
2018-03-28 20:26 ` [PATCH 3/4] OvmfPkg: annotate "PcdVariableStoreSize := PcdFlashNvStorageVariableSize" Laszlo Ersek
2018-03-30 10:58 ` Ard Biesheuvel
2018-03-28 20:26 ` [PATCH 4/4] OvmfPkg/TlsAuthConfigLib: configure trusted CA certs for HTTPS boot Laszlo Ersek
2018-03-30 11:00 ` Ard Biesheuvel
2018-03-29 4:56 ` [PATCH 0/4] MdeModulePkg, OvmfPkg: support large CA cert list " Palmer, Thomas
2018-03-29 11:57 ` Laszlo Ersek
2018-03-29 18:17 ` Palmer, Thomas
2018-03-30 4:39 ` Gary Lin
2018-03-30 19:43 ` 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=20180328202651.1478-3-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