From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (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 50D73257851 for ; Mon, 13 Jul 2026 07:42:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783928541; cv=none; b=F+rCelufWwPkbWEfY45HP4kBHEqD8Z3PzMj0hYi++TlMWP1VJCil0Zj+VnHTW6HeBDUNxDuiJUAajJBRzscXRekLs3tgpRvHxdu+WErlMGHis4bFFv/c30KxmukD4bhYdHribbgCqcNG8edbB0L9PPydGBVHnIDLXWSHt2Lb/Gk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783928541; c=relaxed/simple; bh=OQGxbnqVRC38qP0oYR9t7YY98ii8+XUmoEQzL2dzZvg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=LF+oj4jgSX8pJgOtQDqtJV/7XByye7D5mpnACoPvX8SRcIRMxmNnu1VoURerAoaje/0tT5RM21t+OSposT0tWALF55jUvkzD4NqMNXs7RasCrW5eZl0lhVwfW+qw0fVv1+kdha/jkyIdYhb7u+wfLxMqgZyQEeL45C/Xem/CX68= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=ufoX6hFM; arc=none smtp.client-ip=91.218.175.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="ufoX6hFM" Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1783928536; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6yoLIAxyc2K4qHLq/6jmB6EcYdYLRcJ9qmXi423/+Yo=; b=ufoX6hFMdIyLPO8Bw5rY8zTYrpNA07qYpWVfVGzOWth22H/31rETGvgoTniThRqaviyYjp htnItLldN4JOMquRcrdmPsuHj2DOHOcAm0DNHDeMEhGdqp39vxpUiAkeDe6HylLlexVVjw HCSJeSNqf3qY+mgdiIs8xFbCmBLuGPs= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Subject: Re: [PATCH 00/18] Another attempt at HVO support on arm64 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Mon, 13 Jul 2026 15:41:35 +0800 Cc: Will Deacon , Catalin Marinas , 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 Content-Transfer-Encoding: quoted-printable Message-Id: <9C56FB0F-AE0E-4975-9D89-AFF110433C49@linux.dev> References: <20260708031129.3503195-1-jthoughton@google.com> <3B2B37B5-16DE-4DB0-8A78-4CB8636C1A86@linux.dev> To: James Houghton X-Migadu-Flow: FLOW_OUT > On Jul 13, 2026, at 12:59, James Houghton = wrote: >=20 > On Thu, Jul 9, 2026 at 9:59=E2=80=AFPM Muchun Song = wrote: >>> On Jul 8, 2026, at 11:11, James Houghton = wrote: >>>=20 >>> Hi everyone, >>>=20 >>> This patch series uses a trick with the Access Flag on CPUs that = support >>> hardware update of the AF to update vmemmap page table entries = without >>> introducing a time window where CPUs accessing the vmemmap might = fault. >>=20 >> Hi James, >>=20 >> I was just looking into the Arm ARM specification regarding the TLB = caching >> behavior to better understand the "AF trick" used here, and came = across a few >> sections that got me a bit confused. >>=20 >> Specifically, Section D8.5.1 [1] states Rule RDWZCQ: >>=20 >> "Descriptors with AF set to zero can never be cached in a TLB. = For more >> information about when translation table entries are = permitted to be >> cached in a TLB, see Translation Lookaside Buffers." >>=20 >> This indeed seems to support the core assumption of the AF trick. = However, when >> following the reference to Section D8.16 "Translation Lookaside = Buffers" [2], it >> defines the following rule for permitted caching (RSQBCS): >>=20 >> "When address translation is enabled, a translation table = entry for an >> in-context translation regime that does not cause a = Translation fault, >> an Address size fault, or an Access flag fault is permitted = to be cached >> in a TLB or intermediate TLB caching structure as the result = of an >> explicit or speculative access." >>=20 >> This is exactly where my confusion lies, as these two descriptions in = the spec >> feel directly contradictory when FEAT_HAF(hardware management of the = Access flag) >> is enabled. >=20 > I don't think it intends to say that "translation table entries with > AF=3D0 may be cached" just because they don't cause Access flag = faults. >=20 > It is likely that this clause was written before FEAT_HAFDBS/FEAT_HAF > existed. Re-reading it with that in mind makes the meaning clearer: > PTEs with AF=3D1 may be cached if the architecture otherwise allows = it. >=20 > There is another clause, in D8.5 "Hardware updates of the translation > tables", I_RGQLZ: "If hardware does not update the AF from 0 to 1, > then the descriptor is not permitted to be cached in a TLB." I think > this supports my interpretation. >=20 > I am convinced that it is impossible for an implementation not to > conform to Rule R_DWZCQ (PTEs with AF=3D0 cannot be cached) while > supporting HW AF correctly. Let me try to explain why. >=20 > For HW AF to function correctly: > 1. Setting AF=3D1 must be done atomically, otherwise hardware could = set > a bit in an invalid PTE. (This would break Linux swp_entrys.) > 2. The AF=3D0 translation cannot be used, otherwise we could > potentially drop AF updates. >=20 > If an implementation used the translation before coherently setting > AF=3D1 to perform an architectural memory access, then it must choose > either to set AF=3D1 on a PTE that may have since changed (perhaps to = an > invalid PTE) or drop the AF update entirely. Either way HW AF is > broken. >=20 > Please also see I_GXGPN: "When the translation of an architecturally > executed memory access occurs, the architecture requires that AF is > set to 1." Thanks for your excellent explanation. >=20 >> On one hand, Section D8.5.1 [1] explicitly uses the word "never" for = AF=3D0 >> descriptors. On the other hand, under FEAT_HAF, an entry with AF=3D0 = does not cause >> an Access flag fault anymore, because the hardware is capable of = updating the AF >> automatically. This technically makes it eligible for speculative = caching under >> Rule RSQBCS in Section D8.16 [2]. >>=20 >> My question is: which part of the spec reflects the actual = architectural intent >> when FEAT_HAF is enabled? Is an entry with AF=3D0 permitted to be = speculatively >> cached in the TLB by the hardware under FEAT_HAF, or does the "never" = in RDWZCQ >> still hold absolute priority? >>=20 >> Please let me know if I have misread the specification or missed some = overriding >> constraints here. >=20 > Thanks for making me look a little harder into this; it's a good > question. I hope my reply above makes you more comfortable with the AF At least to me, what you're saying makes sense. > trick. I also hope to hear more from the Arm folks as well. Yes, it would be best to have an ARM expert here to confirm that our understanding of the manual is completely accurate. Thanks. >=20 > Thanks Muchun!