Currently, the AArch64 MMU page table logic will break down any block
entry that overlaps with the region being mapped, even if the block
entry in question is using the same attributes as the new region.
This means that creating a non-executable mapping inside a region that
is already mapped non-executable at a coarser granularity may trigger a
call to AllocatePages (), which may recurse back into the page table
code to update the attributes on the newly allocated page tables.
Let's avoid this, by preserving the block entry if it already covers the
region being mapped with the correct attributes.
Signed-off-by: Ard Biesheuvel <a...@kernel.org>
---
ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
index 1cf8dc090012..28191938aeb1 100644
--- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
+++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
@@ -251,6 +251,15 @@ UpdateRegionMappingRecursive (
ASSERT (Level < 3);
if (!IsTableEntry (*Entry, Level)) {
+ //
+ // If the region we are trying to map is already covered by a block
+ // entry with the right attributes, don't bother splitting it up.
+ //
+ if (IsBlockEntry (*Entry, Level) &&
+ ((*Entry & TT_ATTRIBUTES_MASK & ~AttributeClearMask) ==
AttributeSetMask)) {
+ continue;
+ }
+
//
// No table entry exists yet, so we need to allocate a page table
// for the next level.
--
2.39.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99802): https://edk2.groups.io/g/devel/message/99802
Mute This Topic: https://groups.io/mt/96835913/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
