From nobody Tue Feb 10 10:54:36 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1585027178; cv=none; d=zohomail.com; s=zohoarc; b=fNYVo+mPxARQjsnx04cIdbSAIUZSc2w4LbiXUKiKuzuEx1UceYhMQTXEpu2cQMJPzwbsDFTrKAWQqe44cKLuZOaQkhBMYWtgQzNJPHlLlks3cWPopv1UQtv/crx145w93paaTDsHoS12Xy6LFP/hH7xKTp1L0leb+P1Y1vlibz0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1585027178; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=OoBNbZUCNsH47VPkekgVJDAcQYTy26NmIx0FN69Yauw=; b=npNz4kRl4P6KEmOfDDoRMQmkTlRy0ZGEghYINN4SkwmRYXiAbhvvhgy2qtRUc7AotactJJXEbexsAxCW4bSbcDG4Eh7ak8O3WzgP1Et/QYomC3QnN0twk5jZP3EmkQgJFWiosV25oXs6t2FHxEUmfv8Z+IiV4DxvheQq/rYFaiM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1585027178090540.2225645713634; Mon, 23 Mar 2020 22:19:38 -0700 (PDT) Received: from localhost ([::1]:42946 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jGbyS-0001xn-Nu for importer@patchew.org; Tue, 24 Mar 2020 01:19:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36930) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jGbu8-0004Zv-09 for qemu-devel@nongnu.org; Tue, 24 Mar 2020 01:15:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jGbu6-0001dg-TG for qemu-devel@nongnu.org; Tue, 24 Mar 2020 01:15:07 -0400 Received: from ozlabs.org ([2401:3900:2:1::2]:48355) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jGbu6-0001Zi-IS; Tue, 24 Mar 2020 01:15:06 -0400 Received: by ozlabs.org (Postfix, from userid 1007) id 48mfZW486Sz9sSL; Tue, 24 Mar 2020 16:14:59 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1585026899; bh=fyHM/yk1VNQZCJUEsX1UnGiM8agi4dpqL7KxP+y+WHE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oHnXJ7ZWgcyMDuaxgHK09TOJ0YBUUf+pbiE5qC631GsHWqi8gGHpWDrvrgNYLDLXR GlwiqFhnk7wdIDlzW4+sZQt70F2xHX5a3SqZUi6Nl8Wl7i/mhLGUPxzuluwWWYmgL9 xj8MpXZi2zMLr8cJ3kZbfvZTrTMlCjdPWaPCvijA= From: David Gibson To: peter.maydell@linaro.org Subject: [PULL 2/7] target/ppc: Fix slbia TLB invalidation gap Date: Tue, 24 Mar 2020 16:14:51 +1100 Message-Id: <20200324051456.256116-3-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200324051456.256116-1-david@gibson.dropbear.id.au> References: <20200324051456.256116-1-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2401:3900:2:1::2 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: aik@ozlabs.ru, qemu-devel@nongnu.org, Nicholas Piggin , groug@kaod.org, qemu-ppc@nongnu.org, clg@kaod.org, David Gibson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" From: Nicholas Piggin slbia must invalidate TLBs even if it does not remove a valid SLB entry, because slbmte can overwrite valid entries without removing their TLBs. As the architecture says, slbia invalidates all lookaside information, not conditionally based on if it removed valid entries. It does not seem possible for POWER8 or earlier Linux kernels to hit this bug because it never changes its kernel SLB translations, and it should always have valid entries if any accesses are made to userspace regions. However other operating systems which may modify SLB entry 0 or do more fancy things with segments might be affected. When POWER9 slbia support is added in the next patch, this becomes a real problem because some new slbia variants don't invalidate all non-zero entries. Signed-off-by: Nicholas Piggin Message-Id: <20200318044135.851716-1-npiggin@gmail.com> Reviewed-by: C=C3=A9dric Le Goater Reviewed-by: Greg Kurz Signed-off-by: David Gibson --- target/ppc/mmu-hash64.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/target/ppc/mmu-hash64.c b/target/ppc/mmu-hash64.c index 34f6009b1e..373d44de74 100644 --- a/target/ppc/mmu-hash64.c +++ b/target/ppc/mmu-hash64.c @@ -100,20 +100,29 @@ void helper_slbia(CPUPPCState *env) PowerPCCPU *cpu =3D env_archcpu(env); int n; =20 + /* + * slbia must always flush all TLB (which is equivalent to ERAT in ppc + * architecture). Matching on SLB_ESID_V is not good enough, because s= lbmte + * can overwrite a valid SLB without flushing its lookaside informatio= n. + * + * It would be possible to keep the TLB in synch with the SLB by flush= ing + * when a valid entry is overwritten by slbmte, and therefore slbia wo= uld + * not have to flush unless it evicts a valid SLB entry. However it is + * expected that slbmte is more common than slbia, and slbia is usually + * going to evict valid SLB entries, so that tradeoff is unlikely to b= e a + * good one. + */ + /* XXX: Warning: slbia never invalidates the first segment */ for (n =3D 1; n < cpu->hash64_opts->slb_size; n++) { ppc_slb_t *slb =3D &env->slb[n]; =20 if (slb->esid & SLB_ESID_V) { slb->esid &=3D ~SLB_ESID_V; - /* - * XXX: given the fact that segment size is 256 MB or 1TB, - * and we still don't have a tlb_flush_mask(env, n, mask) - * in QEMU, we just invalidate all TLBs - */ - env->tlb_need_flush |=3D TLB_NEED_LOCAL_FLUSH; } } + + env->tlb_need_flush |=3D TLB_NEED_LOCAL_FLUSH; } =20 static void __helper_slbie(CPUPPCState *env, target_ulong addr, --=20 2.25.1