public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: devel@edk2.groups.io
Cc: oliver@redhat.com, Gerd Hoffmann <kraxel@redhat.com>,
	Laszlo Ersek <lersek@redhat.com>
Subject: [edk2-devel] [PATCH v3 4/6] OvmfPkg/VirtNorFlashDxe: allow larger writes without block erase
Date: Tue, 16 Jan 2024 18:11:03 +0100	[thread overview]
Message-ID: <20240116171105.37831-5-kraxel@redhat.com> (raw)
In-Reply-To: <20240116171105.37831-1-kraxel@redhat.com>

Raise the limit for writes without block erase from two to four
P30_MAX_BUFFER_SIZE_IN_BYTES blocks.  With this in place almost all efi
variable updates are handled without block erase.  With the old limit
some variable updates (with device paths) took the block erase code
path.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
 OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
index 3d1343b381bc..3d1d20daa1e5 100644
--- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
+++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
@@ -550,13 +550,15 @@ NorFlashWriteSingleBlock (
     return EFI_BAD_BUFFER_SIZE;
   }
 
-  // Pick P30_MAX_BUFFER_SIZE_IN_BYTES (== 128 bytes) as a good start for word
-  // operations as opposed to erasing the block and writing the data regardless
-  // if an erase is really needed.  It looks like most individual NV variable
-  // writes are smaller than 128 bytes.
-  // To avoid pathological cases were a 2 byte write is disregarded because it
-  // occurs right at a 128 byte buffered write alignment boundary, permit up to
-  // twice the max buffer size, and perform two writes if needed.
+  // Pick 4 * P30_MAX_BUFFER_SIZE_IN_BYTES (== 512 bytes) as a good
+  // start for word operations as opposed to erasing the block and
+  // writing the data regardless if an erase is really needed.
+  //
+  // Many NV variable updates are small enough for a a single
+  // P30_MAX_BUFFER_SIZE_IN_BYTES block write.  In case the update is
+  // larger than a single block, or the update crosses a
+  // P30_MAX_BUFFER_SIZE_IN_BYTES boundary (as shown in the diagram
+  // below), or both, we might have to write two or more blocks.
   //
   //    0               128              256
   //    [----------------|----------------]
@@ -578,7 +580,7 @@ NorFlashWriteSingleBlock (
   Start = Offset & ~BOUNDARY_OF_32_WORDS;
   End   = ALIGN_VALUE (Offset + *NumBytes, P30_MAX_BUFFER_SIZE_IN_BYTES);
 
-  if ((End - Start) <= (2 * P30_MAX_BUFFER_SIZE_IN_BYTES)) {
+  if ((End - Start) <= (4 * P30_MAX_BUFFER_SIZE_IN_BYTES)) {
     // Check to see if we need to erase before programming the data into NOR.
     // If the destination bits are only changing from 1s to 0s we can just write.
     // After a block is erased all bits in the block is set to 1.
-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113918): https://edk2.groups.io/g/devel/message/113918
Mute This Topic: https://groups.io/mt/103766776/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  parent reply	other threads:[~2024-01-16 17:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-16 17:10 [edk2-devel] [PATCH v3 0/6] OvmfPkg/VirtNorFlashDxe: fix corruption + misc small improvements Gerd Hoffmann
2024-01-16 17:11 ` [edk2-devel] [PATCH v3 1/6] OvmfPkg/VirtNorFlashDxe: add casts to UINTN and UINT32 Gerd Hoffmann
2024-01-16 17:11 ` [edk2-devel] [PATCH v3 2/6] OvmfPkg/VirtNorFlashDxe: clarify block write logic & fix shadowbuffer reads Gerd Hoffmann
2024-01-16 17:11 ` [edk2-devel] [PATCH v3 3/6] OvmfPkg/VirtNorFlashDxe: add a loop for NorFlashWriteBuffer calls Gerd Hoffmann
2024-01-16 17:11 ` Gerd Hoffmann [this message]
2024-01-16 17:11 ` [edk2-devel] [PATCH v3 5/6] OvmfPkg/VirtNorFlashDxe: ValidateFvHeader: unwritten state is EOL too Gerd Hoffmann
2024-01-16 17:11 ` [edk2-devel] [PATCH v3 6/6] OvmfPkg/VirtNorFlashDxe: move DoErase code block into new function Gerd Hoffmann
2024-01-17 10:20   ` Laszlo Ersek
2024-01-18 20:28 ` [edk2-devel] [PATCH v3 0/6] OvmfPkg/VirtNorFlashDxe: fix corruption + misc small improvements Laszlo Ersek
2024-01-19  7:52   ` Ard Biesheuvel

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=20240116171105.37831-5-kraxel@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