From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CA3F0440A0C for ; Mon, 17 Aug 2026 17:34:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786988064; cv=none; b=UK0MphOgouyBlA9ZxzDkn/nae2npcUKq7rDny+7qpzfa7gyZ3dWqjWbyobY3TB5Owa5Ut+8FgZ3vzunjAX9FA2XVOGBVv8iC+G8GTi3yt6V108iqsHTgWEDj058ED/QkIuamIcfT1vwoF3KbLTGBT1jGcCMdTn+mG/76aFyxROI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786988064; c=relaxed/simple; bh=dQHeVJirWd2OT1TdcvEiO5y7O6Dg5Prwr73YHx3YgGA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BwMYUD6PeOnrHukyKglhLXkUhrBMKsF+jFQNOfz+UWB4DsQDO2Oq1v/KJ+eAxtHzbgi8Q9zzlYnKQO73VFtgZnTbHRdpGoABp5ys1yzAH87N3BH7jmUxcQVqDBybR1p2QqH5Y+kxF4b92XVFmOWPlICsrDolbhQmlsULMkuabVk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=o2j6v1+1; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="o2j6v1+1" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A344514BF; Mon, 17 Aug 2026 10:34:16 -0700 (PDT) Received: from arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7A6483F673; Mon, 17 Aug 2026 10:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1786988060; bh=dQHeVJirWd2OT1TdcvEiO5y7O6Dg5Prwr73YHx3YgGA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=o2j6v1+1kEj7SSVM9Z8novRqGeoQKzjTsL/kODG2VHN9wav2fIVvYLOOsBj2gcsay CORquf427smN+XQJ22xJ1GiiAFsv6aQMXPknWZ3Y2XT7vP+pbPcXpdgPCbLUA9yDAS bl/pMq5IX9UHlSyIxTvkIItls/szRGWTzY4swwyY= Date: Mon, 17 Aug 2026 18:34:16 +0100 From: Catalin Marinas To: James Houghton Cc: Will Deacon , Muchun Song , Oscar Salvador , Nikos Nikoleris , Linu Cherian , Mark Rutland , David Hildenbrand , Andrew Morton , Ryan Roberts , Nanyong Sun , Yu Zhao , Frank van der Linden , David Rientjes , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH 00/18] Another attempt at HVO support on arm64 Message-ID: References: <20260708031129.3503195-1-jthoughton@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260708031129.3503195-1-jthoughton@google.com> Hi James, On Wed, Jul 08, 2026 at 03:11:10AM +0000, James Houghton wrote: > The following Herd litmus test demonstrates the PTE update routine: > > AArch64 TTDFaultlessUpdate > Variant=vmsa > TTHM=HA > { > uint64_t x=1; > uint64_t y=2; > [PTE(x)]=(oa:PA(x), af:1); > 0:X0=PTE(x); 1:X0=PTE(x); > 0:X1=x; 1:X1=x; > pteval_t 0:X2=(oa:PA(x), af:0); > pteval_t 0:X3=(oa:PA(y), af:1); > } > P0 | P1 ; > LDR X4,[X0] | L0: ; > MOV X5,X4 | LDR X2,[X1] ; > CAS X4,X2,[X0] | ; > DSB ISHST | ; > LSR X9,X1,#12 | ; > TLBI VAALE1IS,X9 | ; > DSB ISH | ; > ISB | ; > CAS X2,X3,[X0] | ; > exists > 0:X5=0:X4 /\ (* First CAS must succeed *) > (fault(P1:L0) \/ ~(1:X2=2 \/ 1:X2=1)) > > (* This test should not violate BBM requirements. *) We definitely need a clear statement in the Arm ARM around this. As already raised in this thread, we can assume that AF=0 entries won't be cached in TLB but there's more to the BBM rules. For the dirty bit, we have R_SGJBL, we might need something similar for AF in addition to the BBM rules update. In theory, I think your approach works but we need the memory model experts confirmation and the Arm ARM updated. I'm not entirely clear what the above litmus test guarantees other than not giving a warning. On P1, X2 can be either 1 or 2, otherwise fault but that won't happen with HA. I'd rather have something in the 'exists' rule explicitly (like a TLB conflict abort; not supported AFAIK but maybe that's what fault(P1) was meant to show?). In addition to the above test, I wonder whether we could have P1 do two consecutive reads from [X1] and check the read values. Maybe go through a third mapping, OA(z) with AF=0 after the TLBI or just start with AF=0 on x. Basically any other tests for coherency like read-after-read etc., check that the behaviour is preserved through AF=0 just like going through valid=0 with BBM (that's something that should eventually be runnable on actual hardware to validate where we won't have a BBM warning message). -- Catalin