public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, kraxel@redhat.com
Cc: oliver@redhat.com
Subject: Re: [edk2-devel] [PATCH v2 4/6] OvmfPkg/VirtNorFlashDxe: allow larger writes without block erase
Date: Tue, 16 Jan 2024 13:59:21 +0100	[thread overview]
Message-ID: <975804c8-6958-d567-1af4-71d7e657f521@redhat.com> (raw)
In-Reply-To: <20240115155948.136499-5-kraxel@redhat.com>

On 1/15/24 16:59, Gerd Hoffmann wrote:
> 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>
> ---
>  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 67610d6920f7..d80e9f0a2f3a 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
>    //    [----------------|----------------]
> @@ -577,7 +579,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.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>



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



  reply	other threads:[~2024-01-16 12:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-15 15:59 [edk2-devel] [PATCH v2 0/6] OvmfPkg/VirtNorFlashDxe: fix corruption + misc small improvements Gerd Hoffmann
2024-01-15 15:59 ` [edk2-devel] [PATCH v2 1/6] OvmfPkg/VirtNorFlashDxe: add casts to UINTN and UINT32 Gerd Hoffmann
2024-01-15 19:20   ` Laszlo Ersek
2024-01-15 15:59 ` [edk2-devel] [PATCH v2 2/6] OvmfPkg/VirtNorFlashDxe: clarify block write logic & fix shadowbuffer reads Gerd Hoffmann
2024-01-16 12:48   ` Laszlo Ersek
2024-01-15 15:59 ` [edk2-devel] [PATCH v2 3/6] OvmfPkg/VirtNorFlashDxe: add a loop for NorFlashWriteBuffer calls Gerd Hoffmann
2024-01-16 12:56   ` Laszlo Ersek
2024-01-15 15:59 ` [edk2-devel] [PATCH v2 4/6] OvmfPkg/VirtNorFlashDxe: allow larger writes without block erase Gerd Hoffmann
2024-01-16 12:59   ` Laszlo Ersek [this message]
2024-01-15 15:59 ` [edk2-devel] [PATCH v2 5/6] OvmfPkg/VirtNorFlashDxe: ValidateFvHeader: unwritten state is EOL too Gerd Hoffmann
2024-01-16 13:01   ` Laszlo Ersek
2024-01-15 15:59 ` [edk2-devel] [PATCH v2 6/6] OvmfPkg/VirtNorFlashDxe: move DoErase code block into new function Gerd Hoffmann
2024-01-16 13:44   ` Laszlo Ersek
2024-01-16 15:29     ` 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=975804c8-6958-d567-1af4-71d7e657f521@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