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 84612C36010 for ; Sat, 5 Apr 2025 09:36:40 +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-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ahND9LctfKv33wGeVl9lUFdRTzC7/hS5gDffiQvzIao=; b=3Qaw772vp9iwmGoK2nPjiqMSuQ CAXYjTCPKTBXMAU3rEivr78WEUF+7hMrBKNi3+thMrZCtTyAKJUW80TSKh2dxV5g+/Ts8MnS0wH1T NfC8RbXB6rz5TzdJdJGTk4+vlwJUUH6FwoXsRLZl/d9fYA3y7IOmXN2miKUG9QIbA8bCJkQsr4Agd wNXEmCFY/7EvYGoZBK14VKN1Zz/munYY2DPVsiFT6CGJTHgjhiArelEjBY4AP7cc4xcSjtv+8lWIK kDkGTEQF7HOXewoJWE3RgnOqNr6GYPNpx7nd25iNI0PS5hKfoL6zqann2nEEcjQEq5et0wzqtr9C4 icGH+DDg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.1 #2 (Red Hat Linux)) id 1u0zx2-0000000Dmap-0bEj; Sat, 05 Apr 2025 09:36:32 +0000 Received: from nyc.source.kernel.org ([147.75.193.91]) by bombadil.infradead.org with esmtps (Exim 4.98.1 #2 (Red Hat Linux)) id 1u0zu5-0000000DmHL-1PnE for linux-arm-kernel@lists.infradead.org; Sat, 05 Apr 2025 09:33:30 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id AF311A42F64; Sat, 5 Apr 2025 09:27:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 279DCC4CEE4; Sat, 5 Apr 2025 09:33:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743845608; bh=kriz03AnZEeQQvO1jAPNT+Mky6ppncxoMV3q3M6sSRo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ti+/oISwOwauLDwS0nQMoncUJeCMwNjrfS6t3dHuXPWrwQH0AAyvbqSOh2aJL3As5 ln/1Za6oi7agd2hl3dhzSrmNp9VEMQr5702xR9irXYJ6fQp+xOb+UjhhFS89P0h4nw 8dGM5yX9rYbqSacrDl762Hq70+TznUBdC1J3ebusu0ZeOAfvIAKhBc7BcGRBqRTA/J VCkKGy1nBHNT/YHB/PuGFpWuew4FLjz9ErEjuZKvY7e1/ZZsH522RYW/yUdSfvIMSO np2s53T7AKn/9WV0Dfwm0qnFJpVQ3nBaoPBoRrHDtQUAHMvV7843GxtZi5xVxnihip 1DO1yNeDclc2A== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-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 1u0zu1-002Z6m-Ju; Sat, 05 Apr 2025 10:33:25 +0100 Date: Sat, 05 Apr 2025 10:33:28 +0100 Message-ID: <87wmbzx89j.wl-maz@kernel.org> From: Marc Zyngier To: Mingwei Zhang Cc: Oliver Upton , Raghavendra Rao Ananta , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Oliver Upton Subject: Re: [PATCH v2 2/2] KVM: selftests: arm64: Explicitly set the page attrs to Inner-Shareable In-Reply-To: References: <20250405001042.1470552-1-rananta@google.com> <20250405001042.1470552-3-rananta@google.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/30.1 (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=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: mizhang@google.com, oliver.upton@linux.dev, rananta@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, oupton@google.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-20250405_023329_517776_EEDE4E37 X-CRM114-Status: GOOD ( 39.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 Sat, 05 Apr 2025 08:24:30 +0100, Mingwei Zhang wrote: >=20 > On Fri, Apr 4, 2025 at 7:51=E2=80=AFPM Oliver Upton wrote: > > > > On Fri, Apr 04, 2025 at 05:31:49PM -0700, Mingwei Zhang wrote: > > > On Fri, Apr 4, 2025 at 5:10=E2=80=AFPM Raghavendra Rao Ananta > > > wrote: > > > > > > > > Atomic instructions such as 'ldset' over (global) variables in the = guest > > > > is observed to cause an EL1 data abort with FSC 0x35 (IMPLEMENTATION > > > > DEFINED fault (Unsupported Exclusive or Atomic access)). The observ= ation > > > > was particularly apparent on Neoverse-N3. > > > > > > > > According to ARM ARM DDI0487L.a B2.2.6 (Possible implementation > > > > restrictions on using atomic instructions), atomic instructions are > > > > architecturally guaranteed for Inner Shareable and Outer Shareable > > > > attributes. For Non-Shareable attribute, the atomic instructions are > > > > not atomic and issuing such an instruction can lead to the FSC > > > > mentioned in this case (among other things). > > > > > > > > Moreover, according to DDI0487L.a C3.2.6 (Single-copy atomic 64-byte > > > > load/store), it is implementation defined that a data abort with the > > > > mentioned FSC is reported for the first stage of translation that > > > > provides an inappropriate memory type. It's likely that Neoverse-N3 > > > > chose to implement these two and why we see an FSC of 0x35 in EL1 u= pon > > > > executing atomic instructions. > > > > Ok, can we please drop this second reference? > > > > This is talking about something else (FEAT_LS64) that happens to share > > the same FSC as an unsupported atomic instruction. I mentioned this to > > you internally as an illustration of how different implementations may > > behave when determining if the attributes support a particular access, > > but it isn't actually relevant to this change. > > > > > nit: It's likely that Neoverse-N3 chose to implement this option (the > > > first option) instead of reporting at the final enabled stage of > > > translation > > > > I would much rather we rely on the language that describes what the > > architecture guarantees rather than speculate as to how Neoverse-N3 > > behaves. > > > > Mentioning that the breakage was observed on Neoverse-N3 is still useful > > to add to the changelog. > > > > > I have minor question here: The DDI0487L C3.2.6 (Single-copy atomic > > > 64-byte load/store) mentioned > > > > > > """ > > > When the instructions access a memory type that is not one of the > > > following, a data abort for unsupported Exclusive or atomic access is > > > generated: > > > > > > =E2=80=A2 Normal Inner Non-cacheable, Outer Non-cacheable. > > > """ > > > > > > So, the above is the "Normal Inner Non-cacheable", but in our case we > > > have "Normal and non-shareable" in stage-1 mapping, right? I know it > > > is very close, but it seems the situation is still only "one bit" away > > > in my understanding... > > > > This citation relates to FEAT_LS64. If you look at B2.2.6 instead, it > > reads: > > > > """ > > The memory types for which it is architecturally guaranteed that the > > atomic instructions will be atomic are: > > > > - Inner Shareable, Inner Write-Back, Outer Write-Back Normal memory > > with Read allocation hints and Write allocation hints and not > > transient. > > > > - Outer Shareable, Inner Write-Back, Outer Write-Back Normal memory > > with Read allocation hints and Write allocation hints and not > > transient. > > """ >=20 > Agree that the above should be the right place to cite. C3.2.6 seems > to discuss atomic instruction with memory attributes bits(which points > to MAIR_EL1 and MAIR_EL2?). In this case, it is more related to > shareability bits instead. Not sure what you mean by this reference to MAIR. These constraints apply to any memory access, including those that are *not* the direct effect of an instruction. For example, an atomic page table update generated by the HW (AF or DB update) is only guaranteed to succeed if the PTW is itself configured to use ISH+WB or OSH+WB, and could otherwise result in any of the ill effects described in B2.2.6. M. --=20 Jazz isn't dead. It just smells funny.