From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: edk2-devel@lists.01.org, leif.lindholm@linaro.org, lersek@redhat.com
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH 2/4] ArmPkg/CpuDxe ARM: avoid unnecessary cache/TLB maintenance
Date: Wed, 1 Mar 2017 14:42:22 +0000 [thread overview]
Message-ID: <1488379344-16273-3-git-send-email-ard.biesheuvel@linaro.org> (raw)
In-Reply-To: <1488379344-16273-1-git-send-email-ard.biesheuvel@linaro.org>
Page and section entries in the page tables are updated using the
helper ArmUpdateTranslationTableEntry(), which cleans the page
table entry to the PoC, and invalidates the TLB entry covering
the page described by the entry being updated.
Since we may be updating section entries, we might be leaving stale
TLB entries at this point (for all pages in the section except the
first one), which will be invalidated wholesale at the end of
SetMemoryAttributes(). At that point, all caches are cleaned *and*
invalidated as well.
This cache maintenance is costly and unnecessary. The TLB maintenance
is only necessary if we updated any section entries, since any page
by page entries that have been updated will have been invalidated
individually by ArmUpdateTranslationTableEntry().
So drop the clean/invalidate of the caches, and only perform the
full TLB flush if UpdateSectionEntries() was called.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
ArmPkg/Drivers/CpuDxe/Arm/Mmu.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
index 046620f79185..fe0ddee447b0 100644
--- a/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
+++ b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
@@ -680,6 +680,7 @@ SetMemoryAttributes (
{
EFI_STATUS Status;
UINT64 ChunkLength;
+ BOOLEAN FlushTlbs;
//
// Ignore invocations that only modify permission bits
@@ -688,6 +689,7 @@ SetMemoryAttributes (
return EFI_SUCCESS;
}
+ FlushTlbs = FALSE;
while (Length > 0) {
if ((BaseAddress % TT_DESCRIPTOR_SECTION_SIZE == 0) &&
Length >= TT_DESCRIPTOR_SECTION_SIZE) {
@@ -700,6 +702,8 @@ SetMemoryAttributes (
Status = UpdateSectionEntries (BaseAddress, ChunkLength, Attributes,
VirtualMask);
+
+ FlushTlbs = TRUE;
} else {
//
@@ -728,16 +732,9 @@ SetMemoryAttributes (
Length -= ChunkLength;
}
- // Flush d-cache so descriptors make it back to uncached memory for subsequent table walks
- // flush and invalidate pages
- //TODO: Do we really need to invalidate the caches everytime we change the memory attributes ?
- ArmCleanInvalidateDataCache ();
-
- ArmInvalidateInstructionCache ();
-
- // Invalidate all TLB entries so changes are synced
- ArmInvalidateTlb ();
-
+ if (FlushTlbs) {
+ ArmInvalidateTlb ();
+ }
return Status;
}
--
2.7.4
next prev parent reply other threads:[~2017-03-01 14:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-01 14:42 [PATCH 0/4] ArmPkg, ArmVirtpkg ARM: enable strict memory protection Ard Biesheuvel
2017-03-01 14:42 ` [PATCH 1/4] ArmPkg/CpuDxe ARM: avoid splitting page table sections unnecessarily Ard Biesheuvel
2017-03-01 14:42 ` Ard Biesheuvel [this message]
2017-03-01 14:42 ` [PATCH 3/4] ArmPkg/CpuDxe ARM: honour RO/XP attributes in SetMemoryAttributes() Ard Biesheuvel
2017-03-01 14:42 ` [PATCH 4/4] ArmVirtPkg: enable PE/COFF image and memory protection for ARM platforms Ard Biesheuvel
2017-03-01 19:05 ` 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=1488379344-16273-3-git-send-email-ard.biesheuvel@linaro.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