From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E9B4D2144A8; Thu, 12 Dec 2024 14:27:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734013623; cv=none; b=h9+zzcvwl5uR3vqG1rcyIBl1z0rCzjYxolKEeDfZ7MgbWVVvI36xZkgxSbPr7j0UoB73ot162RtiqvjwOIZ0zNFZgaw8bPnkyihw2sCf1vpiv3jgCqoNJzpnexAl9jUmsvF+3Zygpswu8DZt+jYc+d5WuWMiPZwq6btA1CZwziE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734013623; c=relaxed/simple; bh=6MPo7a5U4fv2OQP0G0xKutPCOZIplNypB0d4BP0B7X4=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=UfbSyOmfmgb48hxTNPUs8aOenWBipAwjzFVHWYFdUdvoiZqOP2vkuQkIQa6ymzAUChq7DIfTKoLQ2edk4lBKtnPnla7vJtUOJRzS6Mb1FikQJbol1VRFaWnbKjaGln3oDRpASjYFIcBU7r9qWV8xfLbW2oQpxguQnCAEe4ziBDo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=q6PNpVOm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="q6PNpVOm" 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) Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 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.