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 1B2E7E77188 for ; Thu, 2 Jan 2025 12:32:06 +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=z3nrX1F7FlWjBFkebZXd9/O5oWSFgRIqJmb52FLtFTU=; b=hW2zYGSIor0SwLGomfnocd3NWS iFao9grlfYhBttYaWbbjWo4z/PwI/HyC8wZ8HSBzB+/DVRHlv2msv14CW3wEB7axhUwaJiN4U/oHM f/keNczYjdD4odjL0A3OJJe/Qe4fSNJQAzoVJe/JRekSeHgNPRm8N+q/Xxt1tGUI45TLNunA5ZBJg McH4uv7PJu0Mco4McHae1KRjN1c0R8Cw9dHNONbOMtGkQMsziOCqRtop7P3/JfmK6vMhVKybGOovB Rfg3FlN+Sjpcm/fUOt6hzlbv7Inixc0zBCIOYOjYDgT29QJ88BTAzia+KBWZBno/RVkVgvzptaJ4r gm9+JBCQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tTKMi-0000000ALxF-1nFK; Thu, 02 Jan 2025 12:31:52 +0000 Received: from nyc.source.kernel.org ([147.75.193.91]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tTKLX-0000000ALrV-3Elm for linux-arm-kernel@lists.infradead.org; Thu, 02 Jan 2025 12:30:41 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id F0313A41059; Thu, 2 Jan 2025 12:28:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DBE4BC4CED7; Thu, 2 Jan 2025 12:30:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1735821037; bh=5Y53HP2kEwTqZJxhsBAZ3UIGAtplC1vps/WlfAM1w9w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BT+NulpXbRBMoekFmZhX+SBJ+x9krUVQYwp7v87ECmwZd5FMVyfvJeuQDoBP2zX9z mRowweN388f0rC+iFNpRiMrvOnKU+gqnZAEcQRED+0HwVI8xRZB8z45buVtDy7f4KF uRqsN9t56Ak3cTPiTGgSJTa+oj9sxnS/q0zYLwsqiYwFJ6kz4wQbe+wP0Hxk5gy6qZ SjVRMHOoN+SQ3u/67qqp1LnEl6Tntp85lekpEsZlmWKuZ2o3mvecJrqJ1jIEziN5Li d5QTZ10B1u/XQDRS7fv7m7QUeHSChGXnVzgWhEHIi694hQ0sMIyulWoT89HZSoLnrn Ki93Ijyzns/4Q== 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 1tTKLT-008PkE-9O; Thu, 02 Jan 2025 12:30:35 +0000 Date: Thu, 02 Jan 2025 12:30:34 +0000 Message-ID: <86ed1lpfdh.wl-maz@kernel.org> From: Marc Zyngier To: Jonathan Cameron Cc: Will Deacon , Ryan Roberts , =?UTF-8?B?TWlrb8WCYWo=?= Lenczewski ,,, ,,, ,, ,, ,,, ,, , Subject: Re: [RESEND RFC PATCH v1 2/5] arm64: Add BBM Level 2 cpu feature In-Reply-To: <20250102120704.00002984@huawei.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> <86ikrprn7w.wl-maz@kernel.org> <2b1cc228-a8d5-4383-ab25-abbbcccd2e2c@arm.com> <86h678sy00.wl-maz@kernel.org> <5c551e43-78e9-4336-ab16-b55c0d6c7f92@arm.com> <20241219164528.GH24724@willie-the-truck> <20250102120704.00002984@huawei.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: Jonathan.Cameron@huawei.com, will@kernel.org, ryan.roberts@arm.com, miko.lenczewski@arm.com, catalin.marinas@arm.com, 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, yangyicong@huawei.com, guohanjun@huawei.com, wangkefeng.wang@huawei.com, liaochang1@huawei.com, sunnanyong@huawei.com, linuxarm@huawei.com 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-20250102_043039_952430_20420028 X-CRM114-Status: GOOD ( 37.00 ) 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 Hi Jonathan, On Thu, 02 Jan 2025 12:07:04 +0000, Jonathan Cameron wrote: > > On Thu, 19 Dec 2024 16:45:28 +0000 > Will Deacon wrote: > > > On Thu, Dec 12, 2024 at 04:03:52PM +0000, Ryan Roberts wrote: > > > >>> If anything, this should absolutely check for FAR_EL1 and assert that > > > >>> this is indeed caused by such change. > > > >> > > > >> I'm not really sure how we would check this reliably? Without patch 5, the > > > >> problem is somewhat constrained; we could have as many changes in flight as > > > >> there are CPUs so we could keep a list of all the {mm_struct, VA-range} that are > > > >> being modified. But if patch 5 is confirmed to be architecturally sound, then > > > >> there is no "terminating tlbi" so there is no bound on the set of {mm_struct, > > > >> VA-range}'s that could legitimately cause a conflict abort. > > > > > > > > I didn't mean to imply that we should identify the exact cause of the > > > > abort. I was hoping to simply check that FAR_EL1 reports a userspace > > > > VA. Why wouldn't that work? > > > > > > Ahh gottya! Yes agreed, this sounds like the right approach. > > > > Please, can we just not bother handling conflict aborts at all outside of > > KVM? This is all dead code, it's complicated and it doesn't scale to the > > in-kernel use-cases that others want. There's also not been any attempt > > to add the pKVM support for handling host-side conflict aborts from what > > I can tell. > > > > For now, I would suggest limiting this series just to the KVM support > > for handling a broken/malicious guest. If the contpte performance > > improvements are worthwhile (I've asked for data), then let's add support > > for the CPUs that handle the conflict in hardware (I believe this is far > > more common than reporting the abort) so that the in-kernel users can > > benefit whilst keeping the code manageable at the same time. > > > > Hi All, > > Given direction the discussion is going in time to raise a hand. > > Huawei has implementations that support BBML2, and might report TLB conflict > abort after changing block size directly until an appropriate TLB invalidation > instruction completes and this Implementation Choice is architecturally compliant. Compliant, absolutely. That's the letter of the spec. The usefulness aspect is, however, more debatable, and this is what Will is pointing out. Dealing with TLB Conflict aborts is an absolute pain if you need to handle it within the same Translation Regime and using the same TTBR as the one that has generated the fault. So at least for the time being, it might be preferable to only worry about the implementations that will promise to never generate such an abort and quietly perform an invalidation behind the kernel's back. Thanks, M. -- Without deviation from the norm, progress is not possible.