From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AFF9AE77180 for ; Thu, 12 Dec 2024 14:28:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YxoWtrrj82PfmMzPZQF8U9qE4D7WNRpLyjUea1NfnZg=; b=4m7Yb++amrGfpB4Aq26CURER5k qR1m9Re8rclXm3/N49I+yRvPNUUExj8SO5MQk32VlgJzxuukjrv/tyUo6vc7Ag3NhKAkGy59XOmKQ MFSJmAlz0HBGVujEKapBdsnaL7QU1I6/1bXv3nONPFECvWBctqzBZgoMxb7mSH0YP/Z5+VwvWWvhQ 96Aq+/lTIeAxAWAitCDf6XdxuV3tbig1SdzhP9lDqaKUoz7/B7IR6etJDNFBMNnAJ588T5a1Gnvcn mCZhGqvGvXfbGgjNq9sgSfDWRxXEFM5ZpivvgcBYsZ+mi6HyQhrWwRhFwxCAWvHqQGyY3SJEbhQC+ hG18kMNg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tLkAw-00000000bhr-0JV0; Thu, 12 Dec 2024 14:28:22 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tLk9r-00000000bUN-3nvc for linux-arm-kernel@bombadil.infradead.org; Thu, 12 Dec 2024 14:27:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Type:MIME-Version:References: In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=YxoWtrrj82PfmMzPZQF8U9qE4D7WNRpLyjUea1NfnZg=; b=O030dS+EQ9BF4haGtQmw2qEz5n lMWBklHx+d5s/oM//65gzrEQ3vKYUg5gTUDe6MbDRgvHjuP5LIIN9T7eujYJAhwgFwgLqC+nk063L TlAMx4VQsojPaePXPNEFPhkyWbBbidrHUPbGwlgfVaENI6p5RTLonEkEZ6lq6mwb+Mm/6lRqcZOxA 86c3cuAW5ZEGvzKWDcx9dO5dTe6Ne5vn/1bM1YVKWEXdfiUD+k/QVqBFX3qzSp75qJmAKfHs0nOMx qxEZCO2BqsKEY6G4/uUtLz3P8ip0UxsqbSfbwsuU+ayMRR4v/6P5b3HnYGMwk9V8S7SYw6x4vXIa+ WO0PJ6nA==; Received: from dfw.source.kernel.org ([139.178.84.217]) by desiato.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tLk9o-000000044m2-2vxJ for linux-arm-kernel@lists.infradead.org; Thu, 12 Dec 2024 14:27:14 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 4CF455C64B8; Thu, 12 Dec 2024 14:26:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6205FC4CECE; Thu, 12 Dec 2024 14:27:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734013622; bh=6MPo7a5U4fv2OQP0G0xKutPCOZIplNypB0d4BP0B7X4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=q6PNpVOmLPyEw1+IiMCQTZUJKvThRlkRMdbxEe91miFEvsKsKLOR1S08OE2JUOVPX pIUYYoRwECf1Z76DFXGpy6DgZOAs259cE/OWJ93X8eeHIvBk/RDrTh/kzaO45UWhuH JCgLhJ4NjR+06BdPOkfdQrEdaF+sVSivRsuRBKNxvBwISH9PFuk81+9sutjt+sdu2J o/6SvW9yFGuEZAQPhFqVbjF/SUptQkYQLM49oYQ78SO4pIWfyXhPvByCqSO/vEiHUG 3/L7d1ICA8wso23FQLMYHvqEjTnexPnCqOf4UL9Yosn0me5MCQRhcEEIdoRoQOkhVv NxUKET0QXOG/A== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tLk9b-0035tU-WD; Thu, 12 Dec 2024 14:27:00 +0000 Date: Thu, 12 Dec 2024 14:26:59 +0000 Message-ID: <86ikrprn7w.wl-maz@kernel.org> From: Marc Zyngier To: Ryan Roberts Cc: =?UTF-8?B?TWlrb8WCYWo=?= Lenczewski , catalin.marinas@arm.com, will@kernel.org, corbet@lwn.net, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev Subject: Re: [RESEND RFC PATCH v1 2/5] arm64: Add BBM Level 2 cpu feature In-Reply-To: <084c5ada-51af-4c1a-b50a-4401e62ddbd6@arm.com> References: <20241211160218.41404-1-miko.lenczewski@arm.com> <20241211160218.41404-3-miko.lenczewski@arm.com> <87cyhxs3xq.wl-maz@kernel.org> <084c5ada-51af-4c1a-b50a-4401e62ddbd6@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: ryan.roberts@arm.com, miko.lenczewski@arm.com, catalin.marinas@arm.com, will@kernel.org, corbet@lwn.net, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241212_142713_210018_F1560C3C X-CRM114-Status: GOOD ( 36.89 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 12 Dec 2024 10:55:45 +0000, Ryan Roberts wrote: > > On 12/12/2024 08:25, Marc Zyngier wrote: > >> + > >> + local_flush_tlb_all(); > > > > The elephant in the room: if TLBs are in such a sorry state, what > > guarantees we can make it this far? > > I'll leave Miko to respond to your other comments, but I wanted to address this > one, since it's pretty fundamental. We went around this loop internally and > concluded that what we are doing is architecturally sound. > > The expectation is that a conflict abort can only be generated as a result of > the change in patch 4 (and patch 5). That change makes it possible for the TLB > to end up with a multihit. But crucially that can only happen for user space > memory because that change only operates on user memory. And while the TLB may > detect the conflict at any time, the conflict abort is only permitted to be > reported when an architectural access is prevented by the conflict. So we never > do anything that would allow a conflict for a kernel memory access and a user > memory conflict abort can never be triggered as a result of accessing kernel memory. > > Copy/pasting comment from AlexC on the topic, which explains it better than I can: > > """ > The intent is certainly that in cases where the hardware detects a TLB conflict > abort, it is only permitted to report it (by generating an exception) if it > applies to an access that is being attempted architecturally. ... that property > can be built from the following two properties: > > 1. The TLB conflict can only be reported as an Instruction Abort or a Data Abort > > 2. Those two exception types must be reported synchronously and precisely. > """ I totally agree with this. The issue is that nothing says that the abort is in any way related to userspace. > > > > I honestly don't think you can reliably handle a TLB Conflict abort in > > the same translation regime as the original fault, given that we don't > > know the scope of that fault. You are probably making an educated > > guess that it is good enough on the CPUs you know of, but I don't see > > anything in the architecture that indicates the "blast radius" of a > > TLB conflict. > > OK, so I'm claiming that the blast radius is limited to the region of memory > that we are operating on in contpte_collapse() in patch 4. Perhaps we need to go > re-read the ARM and come back with the specific statements that led us to that > conclusion? But we don't know for sure what caused this conflict by the time we arrive in the handler. It could equally be because we have a glaring bug somewhere on the kernel side, even if you are *now* only concerned with userspace. If anything, this should absolutely check for FAR_EL1 and assert that this is indeed caused by such change. Thanks, M. -- Without deviation from the norm, progress is not possible.