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
next prev 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