From patchwork Wed May 25 02:23:56 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicholas Piggin X-Patchwork-Id: 1635251 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=V4qeBelQ; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org (client-ip=112.213.38.117; helo=lists.ozlabs.org; envelope-from=linuxppc-dev-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org; receiver=) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4L7FJq0TC7z9sGS for ; Wed, 25 May 2022 12:24:59 +1000 (AEST) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4L7FJp6NHtz3cC1 for ; Wed, 25 May 2022 12:24:58 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=V4qeBelQ; dkim-atps=neutral X-Original-To: linuxppc-dev@lists.ozlabs.org Delivered-To: linuxppc-dev@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::631; helo=mail-pl1-x631.google.com; envelope-from=npiggin@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=V4qeBelQ; dkim-atps=neutral Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4L7FHv48JFz300K for ; Wed, 25 May 2022 12:24:11 +1000 (AEST) Received: by mail-pl1-x631.google.com with SMTP id a17so1325341plb.4 for ; Tue, 24 May 2022 19:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=YSYv2upIcOvZVDliAqo05IwqVpmA0XEgofqYHMEuV/c=; b=V4qeBelQFOh2eD6LinejjOwHEpYWm6yumNX3hPZiYjPM3y69D3g2DPw805oEfp8Uhj Yx5LKOYZOTlccRGCkx2DwlB2ZqWvjAl/kIQSrKJPGAltk/0gebmsIW/J/jVUq11sq6Fs i8uYVLbXz11cwu0OiONWUtRpRLLDuAZTvEz0ZsCiQhGvXHcY8uETkn3PeDwr+pEUSO3f xUN1uMGNdOcUMAayL8b4JCdrVd29Wr3egoQnxlVZ2vQ2UHuXPhi0wE9J5vjPLQrOwd9o 652sDMB7xr0soehQ023N+eec+WuQuEanGz8K8A+7SfUsWBhsZCW8CwRFvTlY/uUPeJWE B27g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=YSYv2upIcOvZVDliAqo05IwqVpmA0XEgofqYHMEuV/c=; b=K3L2j6uaBzLJGtmEQDynwCi6RfeK0EQ3QU+rIGZdSJFtSFXM8PSUlgh5+hBEa0VPSv dXwAv/bvf8JWBIOMsbrznVfEjCtHwqql0heH2/OobHIt0L4wDfrGJXpM+H5ProGJe9L2 +EOM9T6vItNZvH18C6swrbo7bMKIouX6pa3hgI0r83sPvwFA6Xrod5DVKymckYdg+7JP sKgjvov9V/tKcgju0OxjlX/xZdb2ZzAk3G2ejBsP8OLpmz90Fl6QRRx5JBQOA4BCtRmp AArL1RZe54+eEvmwBPBPf5Zs3oJgHBcX9NicKpZCBRIHKTztervx8TsN1XxpabkpjOE+ PMyA== X-Gm-Message-State: AOAM530858ZL7c3kDIe1wLAkOLXYm8oUIu/qYB2bdhekKvFqPbPMTnF2 /HO9irBAwAx+o2nQv1yMnRXBZEdzSr8= X-Google-Smtp-Source: ABdhPJxcge3HCynCJcv2bTvIiGDvvjwAs6ZDJHTVGRBzbMEOCwz9XHu9qKPMqZDxuSkp5gsO6CpzUw== X-Received: by 2002:a17:90b:3902:b0:1e0:50ef:3ff3 with SMTP id ob2-20020a17090b390200b001e050ef3ff3mr7656883pjb.137.1653445448994; Tue, 24 May 2022 19:24:08 -0700 (PDT) Received: from bobo.ozlabs.ibm.com ([118.209.250.103]) by smtp.gmail.com with ESMTPSA id p19-20020a1709028a9300b00161a9df4de8sm7884617plo.145.2022.05.24.19.24.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 May 2022 19:24:08 -0700 (PDT) From: Nicholas Piggin To: linuxppc-dev@lists.ozlabs.org Subject: [PATCH 1/3] powerpc/64s: POWER10 nest MMU does not require flush escalation workaround Date: Wed, 25 May 2022 12:23:56 +1000 Message-Id: <20220525022358.780745-2-npiggin@gmail.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220525022358.780745-1-npiggin@gmail.com> References: <20220525022358.780745-1-npiggin@gmail.com> MIME-Version: 1.0 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Aneesh Kumar K . V" , Haren Myneni , Nicholas Piggin Errors-To: linuxppc-dev-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" Per (non-public) Nest MMU Workbook, POWER10 and POWER9P NMMU does not cache PTEs in PWC, so does not require PWC flush to invalidate these translations. Skip the workaround on POWER10 and later. Signed-off-by: Nicholas Piggin --- arch/powerpc/mm/book3s64/radix_tlb.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c b/arch/powerpc/mm/book3s64/radix_tlb.c index 7724af19ed7e..7e233829b453 100644 --- a/arch/powerpc/mm/book3s64/radix_tlb.c +++ b/arch/powerpc/mm/book3s64/radix_tlb.c @@ -755,10 +755,18 @@ EXPORT_SYMBOL(radix__local_flush_tlb_page); static bool mm_needs_flush_escalation(struct mm_struct *mm) { /* - * P9 nest MMU has issues with the page walk cache - * caching PTEs and not flushing them properly when - * RIC = 0 for a PID/LPID invalidate + * The P9 nest MMU has issues with the page walk cache caching PTEs + * and not flushing them when RIC = 0 for a PID/LPID invalidate. + * + * This may have been fixed in shipping firmware (by disabling PWC + * or preventing it from caching PTEs), but until that is confirmed, + * this workaround is required - escalate all RIC=0 IS=1/2/3 flushes + * to RIC=2. + * + * POWER10 (and P9P) does not have this problem. */ + if (cpu_has_feature(CPU_FTR_ARCH_31)) + return false; if (atomic_read(&mm->context.copros) > 0) return true; return false; From patchwork Wed May 25 02:23:57 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicholas Piggin X-Patchwork-Id: 1635252 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=lYcOVfiN; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org (client-ip=2404:9400:2:0:216:3eff:fee1:b9f1; helo=lists.ozlabs.org; envelope-from=linuxppc-dev-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org; receiver=) Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2404:9400:2:0:216:3eff:fee1:b9f1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4L7FKT5CN0z9sGS for ; Wed, 25 May 2022 12:25:33 +1000 (AEST) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4L7FKT2YjSz3c5C for ; Wed, 25 May 2022 12:25:33 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=lYcOVfiN; dkim-atps=neutral X-Original-To: linuxppc-dev@lists.ozlabs.org Delivered-To: linuxppc-dev@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::631; helo=mail-pl1-x631.google.com; envelope-from=npiggin@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=lYcOVfiN; dkim-atps=neutral Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4L7FJ03BT2z300K for ; Wed, 25 May 2022 12:24:16 +1000 (AEST) Received: by mail-pl1-x631.google.com with SMTP id a17so1325341plb.4 for ; Tue, 24 May 2022 19:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=UKRHNhzXOhCCAytx+2499bnluNaoNyH6qwooIgwqcVM=; b=lYcOVfiNmqMoNDdn42RUKUjvNis3HvYWG2IVJQxJM9aAmMsJQ5PLFakWRpzBfp1WRq c867Zw8UBQ1pwGCUU6shU3zYGckFjN20t/o7P3+j+RptZTwKy0by9+Lr3BHSl4eKz4XM 4GwGnSiAoPQu8InU1PVAws523Ds3T5i/NqgjSSo8rQUgXPB9S/lX1hn0Od+7C47KyMrB j/Vq7RnA8SDazg59oI3j/KngZ2wgGXiea4tWaB3NeTvZD5nB1OYtgPg2LGGATpzFy1T8 jZfm1Mxddpep1EX8pxwGLYkCBe1iYR1A/kpF3Vrp6q7GJvZSRGwMPQo7qkdLxdeihc3q 3exg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=UKRHNhzXOhCCAytx+2499bnluNaoNyH6qwooIgwqcVM=; b=s17+oRfXDqmdvWYReDp+yZnOeuCu7f32MU9KFrH0r5tZXJuARqz8jU882h8Xnah2Aw EOllDbsoPskaLrHkQB22Kf9iTEPeX+15W0ZhLP4eQ9yY0CYg2HNBVXiAvaENqwQtifuo mp4/71B9K6EJrOHLaACjvAMMBWAXc/cbLfTC51ks96AY8/KaZHf8tfSRe5lc8/57mMA7 ty7J8c96SPG4cb2ibcb2x7wW2k6h1PznAuHhaiQnPBuJW7TBXeLvHv8q/USVAEdTCkCj 89qzdpP7bdAmkcA+oKgH9sy6bhyI+rO4I2dp5evlYqP2O5VYCy+2iZGYlB0+a2eIy7tg fYoA== X-Gm-Message-State: AOAM531GHkUNJF6CA8QARPCHLu5MPzHY1IMZBVJXzO+t6P8KGIWXMeQz cyTWrEfFeh5Q5mrerhsNTEBMgJ/mJ2M= X-Google-Smtp-Source: ABdhPJyhd4NzPDUChm0/MkFPf1ZuJlfqASJ0M8EMLx3rpLoBoRg2LZqcB0KWLYjBHxeDJZt8d4Yarg== X-Received: by 2002:a17:90b:1c8e:b0:1dd:24f3:c6f6 with SMTP id oo14-20020a17090b1c8e00b001dd24f3c6f6mr7763187pjb.244.1653445455703; Tue, 24 May 2022 19:24:15 -0700 (PDT) Received: from bobo.ozlabs.ibm.com ([118.209.250.103]) by smtp.gmail.com with ESMTPSA id p19-20020a1709028a9300b00161a9df4de8sm7884617plo.145.2022.05.24.19.24.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 May 2022 19:24:14 -0700 (PDT) From: Nicholas Piggin To: linuxppc-dev@lists.ozlabs.org Subject: [PATCH 2/3] powerpc/64s: POWER10 nest MMU can upgrade PTE access authority without TLB flush Date: Wed, 25 May 2022 12:23:57 +1000 Message-Id: <20220525022358.780745-3-npiggin@gmail.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220525022358.780745-1-npiggin@gmail.com> References: <20220525022358.780745-1-npiggin@gmail.com> MIME-Version: 1.0 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Aneesh Kumar K . V" , Haren Myneni , Nicholas Piggin Errors-To: linuxppc-dev-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" The nest MMU in POWER9 does not re-fetch the PTE in response to permission mismatch, contrary to the architecture[*] and unlike the core MMU. This requires a TLB flush before upgrading permissions of valid PTEs, for any address space with a coprocessor attached. Per (non-public) Nest MMU Workbook, POWER10 nest MMU conforms to the architecture in this regard, so skip the workaround. [*] 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." Signed-off-by: Nicholas Piggin --- arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 10 +++--- arch/powerpc/mm/book3s64/radix_pgtable.c | 35 ++++++++++++-------- 2 files changed, 28 insertions(+), 17 deletions(-) diff --git a/arch/powerpc/mm/book3s64/radix_hugetlbpage.c b/arch/powerpc/mm/book3s64/radix_hugetlbpage.c index 23d3e08911d3..78618c9b618b 100644 --- a/arch/powerpc/mm/book3s64/radix_hugetlbpage.c +++ b/arch/powerpc/mm/book3s64/radix_hugetlbpage.c @@ -103,11 +103,13 @@ void radix__huge_ptep_modify_prot_commit(struct vm_area_struct *vma, struct mm_struct *mm = vma->vm_mm; /* - * To avoid NMMU hang while relaxing access we need to flush the tlb before - * we set the new value. + * POWER9 NMMU must flush the TLB after clearing the PTE before + * installing a PTE with more relaxed access permissions, see + * radix__ptep_set_access_flags. */ - if (is_pte_rw_upgrade(pte_val(old_pte), pte_val(pte)) && - (atomic_read(&mm->context.copros) > 0)) + if (!cpu_has_feature(CPU_FTR_ARCH_31) && + is_pte_rw_upgrade(pte_val(old_pte), pte_val(pte)) && + atomic_read(&mm->context.copros) > 0) radix__flush_hugetlb_page(vma, addr); set_huge_pte_at(vma->vm_mm, addr, ptep, pte); diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c index def04631a74d..195719a6c41c 100644 --- a/arch/powerpc/mm/book3s64/radix_pgtable.c +++ b/arch/powerpc/mm/book3s64/radix_pgtable.c @@ -1018,16 +1018,21 @@ void radix__ptep_set_access_flags(struct vm_area_struct *vma, pte_t *ptep, unsigned long change = pte_val(entry) ^ pte_val(*ptep); /* - * To avoid NMMU hang while relaxing access, we need mark - * the pte invalid in between. + * On POWER9, the NMMU is not able to relax PTE access permissions + * for a translation with a TLB. The PTE must be invalidated, TLB + * flushed before the new PTE is installed. + * + * This only needs to be done for radix, because hash translation does + * flush when updating the linux pte (and we don't support NMMU + * accelerators on HPT on POWER9 anyway XXX: do we?). + * + * POWER10 (and P9P) NMMU does behave as per ISA. */ - if ((change & _PAGE_RW) && atomic_read(&mm->context.copros) > 0) { + if (!cpu_has_feature(CPU_FTR_ARCH_31) && (change & _PAGE_RW) && + atomic_read(&mm->context.copros) > 0) { unsigned long old_pte, new_pte; old_pte = __radix_pte_update(ptep, _PAGE_PRESENT, _PAGE_INVALID); - /* - * new value of pte - */ new_pte = old_pte | set; radix__flush_tlb_page_psize(mm, address, psize); __radix_pte_update(ptep, _PAGE_INVALID, new_pte); @@ -1035,9 +1040,12 @@ void radix__ptep_set_access_flags(struct vm_area_struct *vma, pte_t *ptep, __radix_pte_update(ptep, 0, set); /* * Book3S does not require a TLB flush when relaxing access - * restrictions when the address space is not attached to a - * NMMU, because the core MMU will reload the pte after taking - * an access fault, which is defined by the architecture. + * restrictions when the address space (modulo the POWER9 nest + * MMU issue above) because the MMU will reload the PTE after + * taking an access fault, as defined by the architecture. See + * "Setting a Reference or Change Bit or Upgrading Access + * Authority (PTE Subject to Atomic Hardware Updates)" in + * Power ISA Version 3.1B. */ } /* See ptesync comment in radix__set_pte_at */ @@ -1050,11 +1058,12 @@ void radix__ptep_modify_prot_commit(struct vm_area_struct *vma, struct mm_struct *mm = vma->vm_mm; /* - * To avoid NMMU hang while relaxing access we need to flush the tlb before - * we set the new value. We need to do this only for radix, because hash - * translation does flush when updating the linux pte. + * POWER9 NMMU must flush the TLB after clearing the PTE before + * installing a PTE with more relaxed access permissions, see + * radix__ptep_set_access_flags. */ - if (is_pte_rw_upgrade(pte_val(old_pte), pte_val(pte)) && + if (!cpu_has_feature(CPU_FTR_ARCH_31) && + is_pte_rw_upgrade(pte_val(old_pte), pte_val(pte)) && (atomic_read(&mm->context.copros) > 0)) radix__flush_tlb_page(vma, addr); From patchwork Wed May 25 02:23:58 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicholas Piggin X-Patchwork-Id: 1635253 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=JWwg+WJ1; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org (client-ip=2404:9400:2:0:216:3eff:fee1:b9f1; helo=lists.ozlabs.org; envelope-from=linuxppc-dev-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org; receiver=) Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2404:9400:2:0:216:3eff:fee1:b9f1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4L7FLB1TVLz9sGS for ; Wed, 25 May 2022 12:26:10 +1000 (AEST) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4L7FLB0BN4z3cFT for ; Wed, 25 May 2022 12:26:10 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=JWwg+WJ1; dkim-atps=neutral X-Original-To: linuxppc-dev@lists.ozlabs.org Delivered-To: linuxppc-dev@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::42b; helo=mail-pf1-x42b.google.com; envelope-from=npiggin@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=JWwg+WJ1; dkim-atps=neutral Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4L7FJ510DBz30BV for ; Wed, 25 May 2022 12:24:20 +1000 (AEST) Received: by mail-pf1-x42b.google.com with SMTP id y189so2934032pfy.10 for ; Tue, 24 May 2022 19:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=akfecTqLXRL2Zzgz/Ealq707UwMR3lHCQN1YGS4uSBw=; b=JWwg+WJ1dShepXxhPoelvQAIDVFH91RCFdmcLe67ZBK7f3AKBm7QbeKhhWJrRmBI/B 7jll3PwBzJSR1cXDDSUYsRX2Uq5vm7kd3sq6VT3zkOzQojt9eoEkFcaYrZaqw6FffUC5 CknA5w+k9hEIV07KOY9JiTUQQJJLi/nXVESSJjzEvf1fUR+lhiXp/OpJiA9c5qzei+Mw s/CG14I4Iuxco9zISUYjd5Di+h7Azva1cEAcDwJ1nfSgg/9k2jPjI8c0hGmfuoHGTbs0 3HMgqJlyO9giL0103iUbtZP/pSWEDfLLehJlvG/o4cR73c3evCi6Dq0QmJao77026BhQ H8Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=akfecTqLXRL2Zzgz/Ealq707UwMR3lHCQN1YGS4uSBw=; b=CXgnDJFhWvCY7mjX2KRsXpUxsNlbR8nXmeBRKe2PUSCmuuBMzSxGXZn7Fl5uvdHBVN 2mgK75MIQaeFbhZPArrPUUBXbfug9HzWqrEnzvdyYkzGlfeLpuqtBhH43cxCpGhXZCed YVEge6T3E6ffDMgzNt6ZoKK2qI0OQf0nbPasLAhEGZT8prmKCnDo4XQcF/QxZq1KIy3Q bbgPw0KTxxRN3gbwwUpM/B9MxnN6E4psfRYRklXRGEH7jiByONgMO0QWkJtkdHoEvlqm 5PzgDpI/WEmprXGObYDHhbkAX03FxNohN0ep3EdISifngVC4Wa4mZ0LVmEwokIIrdvbZ HDVg== X-Gm-Message-State: AOAM532SIOzv4rIES3jSQggVoHHoEuQQ/6ChGefowLEQv4G9pen9Whul C5G4jDFlPYUThgwp9Y+uIrG2yIq4KZg= X-Google-Smtp-Source: ABdhPJw4lbzqT8rT2AvJeP3yoCexg1nF++QFn4fvvE8YSloSkngYe/uCg6O/xe2zBPtmFSAXto4M4w== X-Received: by 2002:a05:6a00:1a55:b0:518:a189:8f7e with SMTP id h21-20020a056a001a5500b00518a1898f7emr12472308pfv.48.1653445458668; Tue, 24 May 2022 19:24:18 -0700 (PDT) Received: from bobo.ozlabs.ibm.com ([118.209.250.103]) by smtp.gmail.com with ESMTPSA id p19-20020a1709028a9300b00161a9df4de8sm7884617plo.145.2022.05.24.19.24.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 May 2022 19:24:18 -0700 (PDT) From: Nicholas Piggin To: linuxppc-dev@lists.ozlabs.org Subject: [PATCH 3/3] powerpc/64s: Remove spurious fault flushing for NMMU Date: Wed, 25 May 2022 12:23:58 +1000 Message-Id: <20220525022358.780745-4-npiggin@gmail.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220525022358.780745-1-npiggin@gmail.com> References: <20220525022358.780745-1-npiggin@gmail.com> MIME-Version: 1.0 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Aneesh Kumar K . V" , Haren Myneni , Nicholas Piggin Errors-To: linuxppc-dev-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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 --- 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;