From: Laszlo Ersek <lersek@redhat.com>
To: Jordan Justen <jordan.l.justen@intel.com>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>,
Gary Ching-Pang Lin <glin@suse.com>
Subject: Re: [PATCH v2 3/5] OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK
Date: Fri, 5 May 2017 14:07:25 +0200 [thread overview]
Message-ID: <9ff79644-8767-bf10-7d0a-2f5ab6555e23@redhat.com> (raw)
In-Reply-To: <149397463765.13335.18098739662202283758@jljusten-skl>
[-- Attachment #1: Type: text/plain, Size: 5024 bytes --]
On 05/05/17 10:57, Jordan Justen wrote:
> On 2017-05-04 21:07:24, Laszlo Ersek wrote:
>> On 05/03/17 23:39, Laszlo Ersek wrote:
>>> - Raise VARS_LIVE_SIZE by 8KB to 256KB, VARS_SPARE_SIZE by 8KB to 264KB,
>> Unfortunately, we have a terrible regression here. :(
>>
> <snip>
>
>> Adapting EmuVariableFvbRuntimeDxe to a non-power-of-two NV spare area
>> size is hopeless. (Definitely hopeless for the time frame & resources
>> I'm looking at.)
>>
>> Worse, even -pflash is broken in the 4MB build, actually. The
>> non-power-of-two NV spare area size, when used as Alignment for
>> AllocateAlignedRuntimePages() in ReserveEmuVariableNvStore(), triggers
>> an assertion. And this path is taken for the -pflash boot as well.
> For a short term fix, would something like this work?
Absolutely. I didn't dare ask for it.
> 1. Force emu fvb buffer alignment to next power-of-two
>
> Something like the attachment, but I'm guessing you already wrote
> something similar.
Yes, I have almost exactly that; please see the attached
"OvmfPkg/PlatformPei: handle non-power-of-two spare size for emu variables".
The difference is that your patch uses HighBitSet32() directly, which
mine uses through GetPowerOfTwo32(). Also yours starts with the full
size, and then subtracts one for the shift in the alignment; mine starts
with half the size (i.e., the spare area size) and uses that in the
alignment.
One other comment on the patch:
> 0001-PlatformPei-Force-EmuVariableNvStore-alignment-size-.patch
>
>
> From 58ba393adf60caf806b26dec9aa56d936743f595 Mon Sep 17 00:00:00 2001
> From: Jordan Justen <jordan.l.justen@intel.com>
> Date: Fri, 5 May 2017 01:43:31 -0700
> Subject: [PATCH] PlatformPei: Force EmuVariableNvStore alignment size to power
> of two
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
> ---
> OvmfPkg/PlatformPei/Platform.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
> index 77a8a16c15..97dce8de92 100644
> --- a/OvmfPkg/PlatformPei/Platform.c
> +++ b/OvmfPkg/PlatformPei/Platform.c
> @@ -504,6 +504,14 @@ ReserveEmuVariableNvStore (
> {
> EFI_PHYSICAL_ADDRESS VariableStore;
> RETURN_STATUS PcdStatus;
> + UINT32 EmuFvbSize;
> + INTN SizeHighBit;
> +
> + EmuFvbSize = 2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize);
> + SizeHighBit = HighBitSet32 (EmuFvbSize);
> + if ((EmuFvbSize & (EmuFvbSize - 1)) != 0) {
> + SizeHighBit++;
> + }
>
> //
> // Allocate storage for NV variables early on so it will be
> @@ -514,13 +522,13 @@ ReserveEmuVariableNvStore (
> VariableStore =
> (EFI_PHYSICAL_ADDRESS)(UINTN)
> AllocateAlignedRuntimePages (
> - EFI_SIZE_TO_PAGES (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)),
> - PcdGet32 (PcdFlashNvStorageFtwSpareSize)
> + EFI_SIZE_TO_PAGES (EmuFvbSize),
I think we should cast EmuFvbSize to UINTN first; EFI_SIZE_TO_PAGES()
likes the "Size" parameter to be UINTN.
> + 1 << (SizeHighBit - 1)
> );
> DEBUG ((EFI_D_INFO,
> "Reserved variable store memory: 0x%lX; size: %dkb\n",
> VariableStore,
> - (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)) / 1024
> + EmuFvbSize / 1024
> ));
> PcdStatus = PcdSet64S (PcdEmuVariableNvStoreReserved, VariableStore);
> ASSERT_RETURN_ERROR (PcdStatus);
> -- 2.11.0
>
Which one do you prefer:
(1) I can take your patch, stick in the UINTN cast, and expand the
commit message a bit (similarly to what's on my patch),
(2) we can go with my patch as well.
I'm tempted to do (1) and commit it with my R-b immediately, but I
realize that "rushing it" is the root of all evil. So I won't rush it.
On 05/05/17 10:57, Jordan Justen wrote:
> 2. Revert 4MB by default patch
>
> This should allow you to start using the 4MB layout for your builds,
> and we can fix the non-flash path before re-enabling 4MB as the
> default.
This works for me, yes. Thank you.
Regarding the non-flash path, I have the attached work-in-progress patches:
- "OvmfPkg: sync PcdVariableStoreSize with PcdFlashNvStorageVariableSize",
- and "wip".
I think that the "wip" patch does all the "simple" fixes in
EmuVariableFvbRuntimeDxe, and what remains is to add code so that the
FVB protocol members actually do their job. Also, the "wip" patch
eliminates any special alignment in the AllocateRuntimePages() call of
PlatformPei, since after the "block size = page size" change, no such
alignment will be necessary. What do you think of this?
So here's the plan:
- based on what you prefer for (1) vs. (2), I'll post that patch as
first patch,
- I'll post the revert of the 4MB default as second patch,
- I think I'll immediately post the patch that syncs
PcdVariableStoreSize as well, as third patch, because it is a small
improvement for the pflash case too.
Does this work for you?
Thank you,
Laszlo
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-OvmfPkg-PlatformPei-handle-non-power-of-two-spare-si.patch --]
[-- Type: text/x-patch; name="0001-OvmfPkg-PlatformPei-handle-non-power-of-two-spare-si.patch", Size: 2833 bytes --]
From 7bd8738556abb86bdbfdd11dd30ad78663925c09 Mon Sep 17 00:00:00 2001
From: Laszlo Ersek <lersek@redhat.com>
Date: Fri, 5 May 2017 02:35:21 +0200
Subject: [PATCH] OvmfPkg/PlatformPei: handle non-power-of-two spare size for
emu variables
In commit b24fca05751f ("OvmfPkg: introduce 4MB flash image (mainly) for
Windows HCK", 2017-04-29), I changed PcdFlashNvStorageFtwSpareSize to
264KB, in the (new default) 4MB build.
While PcdFlashNvStorageFtwSpareSize remains exactly half of the entire
non-volatile store (which is 528KB), 264KB isn't itself a power of two.
This triggers an assertion failure in AllocateAlignedRuntimePages() when
PlatformPei calls it from the ReserveEmuVariableNvStore() function,
passing PcdFlashNvStorageFtwSpareSize as the Alignment parameter:
> ASSERT MdePkg/Library/PeiMemoryAllocationLib/MemoryAllocationLib.c(196):
> (Alignment & (Alignment - 1)) == 0
Round up the alignment to the next power of two if necessary.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Fixes: b24fca05751f8222acf264853709012e0ab7bf49
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
OvmfPkg/PlatformPei/Platform.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 77a8a16c15b8..5e983a8dcea9 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -504,6 +504,7 @@ ReserveEmuVariableNvStore (
{
EFI_PHYSICAL_ADDRESS VariableStore;
RETURN_STATUS PcdStatus;
+ UINT32 Alignment;
//
// Allocate storage for NV variables early on so it will be
@@ -511,16 +512,26 @@ ReserveEmuVariableNvStore (
// across reboots, this allows the NV variable storage to survive
// a VM reboot.
//
+ Alignment = PcdGet32 (PcdFlashNvStorageFtwSpareSize);
+ if ((Alignment & (Alignment - 1)) != 0) {
+ //
+ // Round up Alignment to the next power of two.
+ //
+ Alignment = GetPowerOfTwo32 (Alignment) << 1;
+ }
+
VariableStore =
(EFI_PHYSICAL_ADDRESS)(UINTN)
AllocateAlignedRuntimePages (
EFI_SIZE_TO_PAGES (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)),
- PcdGet32 (PcdFlashNvStorageFtwSpareSize)
+ Alignment
);
DEBUG ((EFI_D_INFO,
- "Reserved variable store memory: 0x%lX; size: %dkb\n",
+ "Reserved variable store memory: 0x%lX; size: %dkb, "
+ "alignment: 0x%x\n",
VariableStore,
- (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)) / 1024
+ (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)) / 1024,
+ Alignment
));
PcdStatus = PcdSet64S (PcdEmuVariableNvStoreReserved, VariableStore);
ASSERT_RETURN_ERROR (PcdStatus);
--
2.9.3
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0001-OvmfPkg-sync-PcdVariableStoreSize-with-PcdFlashNvSto.patch --]
[-- Type: text/x-patch; name="0001-OvmfPkg-sync-PcdVariableStoreSize-with-PcdFlashNvSto.patch", Size: 4236 bytes --]
From 2d6500afb5870e577bab93ef9f54cab9e930703e Mon Sep 17 00:00:00 2001
From: Laszlo Ersek <lersek@redhat.com>
Date: Fri, 5 May 2017 03:31:32 +0200
Subject: [PATCH 1/2] OvmfPkg: sync PcdVariableStoreSize with
PcdFlashNvStorageVariableSize
"MdeModulePkg/MdeModulePkg.dec" declares PcdVariableStoreSize like this:
> The size of volatile buffer. This buffer is used to store VOLATILE
> attribute variables.
There is no inherent reason why the size of the volatile variable store
should match the same of the non-volatile variable store. Indeed flash
variables in the 4MB build work fine without this equality.
However, OvmfPkg/EmuVariableFvbRuntimeDxe uses PcdVariableStoreSize to
initialize the non-volatile VARIABLE_STORE_HEADER too. (Presumably based
on the fact that ultimately that storage will not be permanent.) When
using EmuVariableFvbRuntimeDxe in the 4MB build, the mismatch between the
two mentioned PCDs (which is apparent through EmuVariableFvbRuntimeDxe's
VARIABLE_STORE_HEADER) triggers an assertion in the variable driver:
> ASSERT MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c(3772):
> mNvVariableCache->Size == VariableStoreLength
Bringing PcdVariableStoreSize in sync with PcdFlashNvStorageVariableSize
fixes this. It also happens to ensure a volatile store size in the 4MB
build that equals the non-volatile store size, which likely doesn't hurt
for symmetry.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Fixes: b24fca05751f8222acf264853709012e0ab7bf49
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
OvmfPkg/OvmfPkgIa32.dsc | 3 ++-
OvmfPkg/OvmfPkgIa32X64.dsc | 3 ++-
OvmfPkg/OvmfPkgX64.dsc | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index e0ff7ead034e..4f518661e3b6 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -417,12 +417,13 @@ [PcdsFixedAtBuild]
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
!endif
!if $(FD_SIZE_IN_KB) == 4096
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x40000
!endif
- gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 41922f581c98..4551021f5efa 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -422,12 +422,13 @@ [PcdsFixedAtBuild]
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
!endif
!if $(FD_SIZE_IN_KB) == 4096
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x40000
!endif
- gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 9ba033956c88..f993d392ce9c 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -422,12 +422,13 @@ [PcdsFixedAtBuild]
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
!endif
!if $(FD_SIZE_IN_KB) == 4096
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400
+ gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x40000
!endif
- gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
--
2.9.3
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0002-wip.patch --]
[-- Type: text/x-patch; name="0002-wip.patch", Size: 5165 bytes --]
From 065349ecf62e0ec8b0cb40384bf43e6af863a4de Mon Sep 17 00:00:00 2001
From: Laszlo Ersek <lersek@redhat.com>
Date: Fri, 5 May 2017 04:26:47 +0200
Subject: [PATCH 2/2] wip
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.h | 10 +++++++--
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c | 23 +++++++++++---------
OvmfPkg/PlatformPei/Platform.c | 5 ++---
3 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.h b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.h
index f34fad2cdd48..090b218aaf55 100644
--- a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.h
+++ b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.h
@@ -58,8 +58,14 @@ typedef struct {
//
// Constants
//
-#define EMU_FVB_BLOCK_SIZE (FixedPcdGet32 (PcdFlashNvStorageFtwSpareSize))
-#define EMU_FVB_SIZE (2 * FixedPcdGet32 (PcdFlashNvStorageFtwSpareSize))
+#define EMU_FVB_BLOCK_SIZE \
+ EFI_PAGE_SIZE
+#define EMU_FVB_NUM_SPARE_BLOCKS \
+ EFI_SIZE_TO_PAGES ((UINTN)FixedPcdGet32 (PcdFlashNvStorageFtwSpareSize))
+#define EMU_FVB_NUM_TOTAL_BLOCKS \
+ (2 * EMU_FVB_NUM_SPARE_BLOCKS)
+#define EMU_FVB_SIZE \
+ (EMU_FVB_NUM_TOTAL_BLOCKS * EMU_FVB_BLOCK_SIZE)
#define FTW_WRITE_QUEUE_SIZE \
(FixedPcdGet32 (PcdFlashNvStorageFtwWorkingSize) - \
sizeof (EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER))
diff --git a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
index dec6d4af50df..990910deb227 100644
--- a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
+++ b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
@@ -74,8 +74,8 @@ EFI_FW_VOL_BLOCK_DEVICE mEmuVarsFvb = {
}
},
NULL, // BufferPtr
- FixedPcdGet32 (PcdFlashNvStorageFtwSpareSize), // BlockSize
- 2 * FixedPcdGet32 (PcdFlashNvStorageFtwSpareSize), // Size
+ EMU_FVB_BLOCK_SIZE, // BlockSize
+ EMU_FVB_SIZE, // Size
{ // FwVolBlockInstance
FvbProtocolGetAttributes,
FvbProtocolSetAttributes,
@@ -185,14 +185,14 @@ FvbProtocolGetBlockSize (
{
EFI_FW_VOL_BLOCK_DEVICE *FvbDevice;
- if (Lba > 1) {
+ if (Lba > EMU_FVB_NUM_TOTAL_BLOCKS - 1) {
return EFI_INVALID_PARAMETER;
}
FvbDevice = FVB_DEVICE_FROM_THIS (This);
*BlockSize = FvbDevice->BlockSize;
- *NumberOfBlocks = (UINTN) (2 - (UINTN) Lba);
+ *NumberOfBlocks = (UINTN) (EMU_FVB_NUM_TOTAL_BLOCKS - (UINTN) Lba);
return EFI_SUCCESS;
}
@@ -345,7 +345,9 @@ FvbProtocolEraseBlocks (
//
// Check input parameters
//
- if ((NumOfLba == 0) || (StartingLba > 1) || ((StartingLba + NumOfLba) > 2)) {
+ if ((NumOfLba == 0) ||
+ (StartingLba > EMU_FVB_NUM_TOTAL_BLOCKS - 1) ||
+ ((StartingLba + NumOfLba) > EMU_FVB_NUM_TOTAL_BLOCKS)) {
VA_END (args);
return EFI_INVALID_PARAMETER;
}
@@ -353,7 +355,7 @@ FvbProtocolEraseBlocks (
if (StartingLba == 0) {
Erase = (UINT8) (Erase | BIT0);
}
- if ((StartingLba + NumOfLba) == 2) {
+ if ((StartingLba + NumOfLba) == EMU_FVB_NUM_TOTAL_BLOCKS) {
Erase = (UINT8) (Erase | BIT1);
}
@@ -663,7 +665,7 @@ InitializeFvAndVariableStoreHeaders (
// EFI_FV_BLOCK_MAP_ENTRY BlockMap[1];
{
{
- 2, // UINT32 NumBlocks;
+ EMU_FVB_NUM_TOTAL_BLOCKS, // UINT32 NumBlocks;
EMU_FVB_BLOCK_SIZE // UINT32 Length;
}
}
@@ -732,7 +734,7 @@ InitializeFvAndVariableStoreHeaders (
// EFI_FV_BLOCK_MAP_ENTRY BlockMap[1];
{
{
- 2, // UINT32 NumBlocks;
+ EMU_FVB_NUM_TOTAL_BLOCKS, // UINT32 NumBlocks;
EMU_FVB_BLOCK_SIZE // UINT32 Length;
}
}
@@ -814,7 +816,7 @@ FvbInitialize (
(PcdGet32 (PcdVariableStoreSize) +
PcdGet32 (PcdFlashNvStorageFtwWorkingSize)
) >
- EMU_FVB_BLOCK_SIZE
+ EMU_FVB_BLOCK_SIZE * EMU_FVB_NUM_SPARE_BLOCKS
) {
DEBUG ((EFI_D_ERROR, "EMU Variable invalid PCD sizes\n"));
return EFI_INVALID_PARAMETER;
@@ -877,7 +879,8 @@ FvbInitialize (
//
// Initialize the Fault Tolerant Write spare block
//
- SubPtr = (VOID*) ((UINT8*) Ptr + EMU_FVB_BLOCK_SIZE);
+ SubPtr = (VOID*) ((UINT8*) Ptr +
+ EMU_FVB_BLOCK_SIZE * EMU_FVB_NUM_SPARE_BLOCKS);
PcdStatus = PcdSet32S (PcdFlashNvStorageFtwSpareBase,
(UINT32)(UINTN) SubPtr);
ASSERT_RETURN_ERROR (PcdStatus);
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 77a8a16c15b8..c2829dbcf5c7 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -513,9 +513,8 @@ ReserveEmuVariableNvStore (
//
VariableStore =
(EFI_PHYSICAL_ADDRESS)(UINTN)
- AllocateAlignedRuntimePages (
- EFI_SIZE_TO_PAGES (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)),
- PcdGet32 (PcdFlashNvStorageFtwSpareSize)
+ AllocateRuntimePages (
+ EFI_SIZE_TO_PAGES (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize))
);
DEBUG ((EFI_D_INFO,
"Reserved variable store memory: 0x%lX; size: %dkb\n",
--
2.9.3
next prev parent reply other threads:[~2017-05-05 12:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-03 21:39 [PATCH v2 0/5] OvmfPkg: add FD_SIZE_4MB for Windows HCK SB tests, and for future proofing Laszlo Ersek
2017-05-03 21:39 ` [PATCH v2 1/5] OvmfPkg: introduce the FD_SIZE_IN_KB macro / build flag Laszlo Ersek
2017-05-03 21:39 ` [PATCH v2 2/5] OvmfPkg/OvmfPkg.fdf.inc: extract VARS_LIVE_SIZE and VARS_SPARE_SIZE macros Laszlo Ersek
2017-05-03 21:39 ` [PATCH v2 3/5] OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK Laszlo Ersek
2017-05-05 4:07 ` Laszlo Ersek
2017-05-05 8:57 ` Jordan Justen
2017-05-05 12:07 ` Laszlo Ersek [this message]
2017-05-05 15:43 ` Jordan Justen
2017-05-05 16:46 ` Laszlo Ersek
2017-05-03 21:39 ` [PATCH v2 4/5] OvmfPkg: raise max variable size (auth & non-auth) to 33KB for FD_SIZE_4MB Laszlo Ersek
2017-05-04 16:36 ` Jordan Justen
2017-05-04 16:52 ` Laszlo Ersek
2017-05-04 18:50 ` Jordan Justen
2017-05-04 19:27 ` Laszlo Ersek
2017-05-04 19:30 ` Laszlo Ersek
2017-05-04 23:00 ` Laszlo Ersek
2017-05-03 21:39 ` [PATCH v2 5/5] OvmfPkg: make the 4MB flash size the default 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=9ff79644-8767-bf10-7d0a-2f5ab6555e23@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