From: Nicholas Piggin <npiggin@gmail•com>
To: linuxppc-dev@lists•ozlabs.org
Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux•ibm.com>,
Haren Myneni <haren@linux•ibm.com>,
Nicholas Piggin <npiggin@gmail•com>
Subject: [PATCH 3/3] powerpc/64s: Remove spurious fault flushing for NMMU
Date: Wed, 25 May 2022 12:23:58 +1000 [thread overview]
Message-ID: <20220525022358.780745-4-npiggin@gmail.com> (raw)
In-Reply-To: <20220525022358.780745-1-npiggin@gmail.com>
Commit 6d8278c414cb2 ("powerpc/64s/radix: do not flush TLB on spurious
fault") removed the TLB flush for spurious faults, except when a
coprocessor (nest MMU) maps the address space. This is not needed
because the NMMU workaround in the PTE permission upgrade paths
prevents PTEs existing with less restrictive access permissions than
their corresponding TLB entries have.
Remove it and replace with a comment.
Signed-off-by: Nicholas Piggin <npiggin@gmail•com>
---
arch/powerpc/include/asm/book3s/64/tlbflush.h | 28 +++++++++++++++++--
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h b/arch/powerpc/include/asm/book3s/64/tlbflush.h
index d2e80f178b6d..ab01938f6c82 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
@@ -138,9 +138,31 @@ static inline void flush_all_mm(struct mm_struct *mm)
static inline void flush_tlb_fix_spurious_fault(struct vm_area_struct *vma,
unsigned long address)
{
- /* See ptep_set_access_flags comment */
- if (atomic_read(&vma->vm_mm->context.copros) > 0)
- flush_tlb_page(vma, address);
+ /*
+ * Book3S 64 does not require spurious fault flushes because the PTE
+ * must be re-fetched in case of an access permission problem. So the
+ * only reason for a spurious fault should be concurrent modification
+ * to the PTE, in which case the PTE will eventually be re-fetched by
+ * the MMU when it attempts the access again.
+ *
+ * See: Power ISA Version 3.1B, 6.10.1.2 Modifying a Translation Table
+ * Entry, Setting a Reference or Change Bit or Upgrading Access
+ * Authority (PTE Subject to Atomic Hardware Updates):
+ *
+ * "If the only change being made to a valid PTE that is subject to
+ * atomic hardware updates is to set the Reference or Change bit to
+ * 1 or to upgrade access authority, a simpler sequence suffices
+ * because the translation hardware will refetch the PTE if an
+ * access is attempted for which the only problems were reference
+ * and/or change bits needing to be set or insufficient access
+ * authority."
+ */
+
+ /*
+ * The nest MMU in POWER9 does not perform this PTE re-fetch, but
+ * it avoids the spurious fault problem by flushing the TLB before
+ * upgrading PTE permissions, see radix__ptep_set_access_flags.
+ */
}
extern bool tlbie_capable;
--
2.35.1
next prev parent reply other threads:[~2022-05-25 2:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-25 2:23 [PATCH 0/3] powerpc/64s: Restrict NMMU workarounds Nicholas Piggin
2022-05-25 2:23 ` [PATCH 1/3] powerpc/64s: POWER10 nest MMU does not require flush escalation workaround Nicholas Piggin
2022-05-25 2:23 ` [PATCH 2/3] powerpc/64s: POWER10 nest MMU can upgrade PTE access authority without TLB flush Nicholas Piggin
2022-05-25 2:23 ` Nicholas Piggin [this message]
2022-07-29 13:02 ` [PATCH 0/3] powerpc/64s: Restrict NMMU workarounds Michael Ellerman
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-all 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=20220525022358.780745-4-npiggin@gmail.com \
--to=npiggin@gmail$(echo .)com \
--cc=aneesh.kumar@linux$(echo .)ibm.com \
--cc=haren@linux$(echo .)ibm.com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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