public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ardb@kernel.org>
To: devel@edk2.groups.io
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Sunil V L <sunilvl@ventanamicro.com>,
	Sami Mujawar <sami.mujawar@arm.com>,
	Leif Lindholm <quic_llindhol@quicinc.com>
Subject: [PATCH 08/11] OvmfPkg/VirtNorFlashDxe: use EFI_MEMORY_WC and drop AlignedCopyMem()
Date: Mon, 24 Oct 2022 19:01:19 +0200	[thread overview]
Message-ID: <20221024170122.594577-9-ardb@kernel.org> (raw)
In-Reply-To: <20221024170122.594577-1-ardb@kernel.org>

NOR flash emulation under KVM involves switching between two modes,
where array mode is backed by a read-only memslot, and programming mode
is fully emulated, i.e., the memory region is not backed by anything,
and the faulting accesses are forwarded to the VMM by the hypervisor,
which translates them into NOR flash programming commands.

Normally, we are limited to the use of device attributes when mapping
such regions, given that the programming mode has MMIO semantics.
However, when running under KVM, the chosen memory attributes only take
effect when in array mode, since no memory mapping exists otherwise.

This means we can tune the memory mapping so it behaves a bit more like
a ROM, by switching to EFI_MEMORY_WC attributes. This means we no longer
need a special CopyMem() implementation that avoids unaligned accesses
at all cost.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c    | 65 +-------------------
 OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.c |  4 +-
 2 files changed, 4 insertions(+), 65 deletions(-)

diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
index d87cdd49d6a6..392e17988472 100644
--- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
+++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
@@ -401,67 +401,6 @@ NorFlashWriteBlocks (
   return Status;
 }
 
-#define BOTH_ALIGNED(a, b, align)  ((((UINTN)(a) | (UINTN)(b)) & ((align) - 1)) == 0)
-
-/**
-  Copy Length bytes from Source to Destination, using aligned accesses only.
-  Note that this implementation uses memcpy() semantics rather then memmove()
-  semantics, i.e., SourceBuffer and DestinationBuffer should not overlap.
-
-  @param  DestinationBuffer The target of the copy request.
-  @param  SourceBuffer      The place to copy from.
-  @param  Length            The number of bytes to copy.
-
-  @return Destination
-
-**/
-STATIC
-VOID *
-AlignedCopyMem (
-  OUT     VOID        *DestinationBuffer,
-  IN      CONST VOID  *SourceBuffer,
-  IN      UINTN       Length
-  )
-{
-  UINT8         *Destination8;
-  CONST UINT8   *Source8;
-  UINT32        *Destination32;
-  CONST UINT32  *Source32;
-  UINT64        *Destination64;
-  CONST UINT64  *Source64;
-
-  if (BOTH_ALIGNED (DestinationBuffer, SourceBuffer, 8) && (Length >= 8)) {
-    Destination64 = DestinationBuffer;
-    Source64      = SourceBuffer;
-    while (Length >= 8) {
-      *Destination64++ = *Source64++;
-      Length          -= 8;
-    }
-
-    Destination8 = (UINT8 *)Destination64;
-    Source8      = (CONST UINT8 *)Source64;
-  } else if (BOTH_ALIGNED (DestinationBuffer, SourceBuffer, 4) && (Length >= 4)) {
-    Destination32 = DestinationBuffer;
-    Source32      = SourceBuffer;
-    while (Length >= 4) {
-      *Destination32++ = *Source32++;
-      Length          -= 4;
-    }
-
-    Destination8 = (UINT8 *)Destination32;
-    Source8      = (CONST UINT8 *)Source32;
-  } else {
-    Destination8 = DestinationBuffer;
-    Source8      = SourceBuffer;
-  }
-
-  while (Length-- != 0) {
-    *Destination8++ = *Source8++;
-  }
-
-  return DestinationBuffer;
-}
-
 EFI_STATUS
 NorFlashReadBlocks (
   IN NOR_FLASH_INSTANCE  *Instance,
@@ -516,7 +455,7 @@ NorFlashReadBlocks (
   SEND_NOR_COMMAND (Instance->DeviceBaseAddress, 0, P30_CMD_READ_ARRAY);
 
   // Readout the data
-  AlignedCopyMem (Buffer, (VOID *)StartAddress, BufferSizeInBytes);
+  CopyMem (Buffer, (VOID *)StartAddress, BufferSizeInBytes);
 
   return EFI_SUCCESS;
 }
@@ -558,7 +497,7 @@ NorFlashRead (
   SEND_NOR_COMMAND (Instance->DeviceBaseAddress, 0, P30_CMD_READ_ARRAY);
 
   // Readout the data
-  AlignedCopyMem (Buffer, (VOID *)(StartAddress + Offset), BufferSizeInBytes);
+  CopyMem (Buffer, (VOID *)(StartAddress + Offset), BufferSizeInBytes);
 
   return EFI_SUCCESS;
 }
diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.c b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.c
index f9a41f6aab0f..ff3121af2a40 100644
--- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.c
+++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.c
@@ -394,14 +394,14 @@ NorFlashFvbInitialize (
                   EfiGcdMemoryTypeMemoryMappedIo,
                   Instance->DeviceBaseAddress,
                   RuntimeMmioRegionSize,
-                  EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
+                  EFI_MEMORY_WC | EFI_MEMORY_RUNTIME
                   );
   ASSERT_EFI_ERROR (Status);
 
   Status = gDS->SetMemorySpaceAttributes (
                   Instance->DeviceBaseAddress,
                   RuntimeMmioRegionSize,
-                  EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
+                  EFI_MEMORY_WC | EFI_MEMORY_RUNTIME
                   );
   ASSERT_EFI_ERROR (Status);
 
-- 
2.35.1


  parent reply	other threads:[~2022-10-24 17:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-24 17:01 [PATCH 00/11] ArmVirtPkg: introduce VirtNorFlashDxe Ard Biesheuvel
2022-10-24 17:01 ` [PATCH 01/11] OvmfPkg: clone NorFlashPlatformLib into VirtNorFlashPlatformLib Ard Biesheuvel
2022-10-24 17:01 ` [PATCH 02/11] OvmfPkg/VirtNorFlashDxe: clone ArmPlatformPkg's NOR flash driver Ard Biesheuvel
2022-10-24 17:01 ` [PATCH 03/11] OvmfPkg/VirtNorFlashDxe: remove CheckBlockLocked feature Ard Biesheuvel
2022-10-24 17:01 ` [PATCH 04/11] OvmfPkg/VirtNorFlashDxe: remove disk I/O protocol implementation Ard Biesheuvel
2022-10-24 17:01 ` [PATCH 05/11] OvmfPkg/VirtNorFlashDxe: drop block " Ard Biesheuvel
2022-10-24 17:01 ` [PATCH 06/11] OvmfPkg/VirtNorFlashDxe: avoid array mode switch after each word write Ard Biesheuvel
2022-10-24 17:01 ` [PATCH 07/11] OvmfPkg/VirtNorFlashDxe: avoid switching between modes in a tight loop Ard Biesheuvel
2022-10-24 17:01 ` Ard Biesheuvel [this message]
2022-10-24 17:01 ` [PATCH 09/11] ArmVirtPkg/ArmVirtQemu: migrate to OVMF's VirtNorFlashDxe Ard Biesheuvel
2022-10-24 17:01 ` [PATCH 10/11] ArmVirtPkg/ArmVirtKvmTool: Migrate " Ard Biesheuvel
2022-10-24 17:01 ` [PATCH 11/11] ArmPlatformPkg: Retire NorFlashDxe driver Ard Biesheuvel
2022-10-25 16:32   ` Leif Lindholm
2022-10-27  4:47 ` [PATCH 00/11] ArmVirtPkg: introduce VirtNorFlashDxe Sunil V L
2022-10-27 16:56   ` 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=20221024170122.594577-9-ardb@kernel.org \
    --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