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 7429F3AAF52 for ; Tue, 18 Aug 2026 16:34:06 +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=1787070848; cv=none; b=GmaXBwf9btTcOW6oEBWaznDLt9LcwEOA1R6QbZcrUBMYL0ViNUnf7ILZs41PNPsPsUS8gMRpdqPXKf4zgpvcc2rPSaUF6FAPmKpGd+JWvb3rHMAyDQrrW4b7AYMd5l04mfQybkBE5N3Dp7wwEm3zHPzAePozphiQSa+YeJ/Y37g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787070848; c=relaxed/simple; bh=roFDoKpIkkJ7bFHN1815WLEntXi/XSfb52O3DVWoU5Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=m80TCFdTbmjIZ/HAShlBNGIJgM5YVgjbKwgRuNa8EayD1xGqpwdo0VL2fQs7ocN+cwY5eFueULeKq8SmnnSYDoLqFUKcm35zXkVdtG7s8zVRwhmYDLQH1EYFoS+0/EMY8oeUmp/DfihdnbODgoCjRconxmEh2u4OjibLXvRNGFE= 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=QJ1erU2E; 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="QJ1erU2E" 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 C893D1A00; Tue, 18 Aug 2026 09:34:01 -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 9EC663F85F; Tue, 18 Aug 2026 09:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1787070845; bh=roFDoKpIkkJ7bFHN1815WLEntXi/XSfb52O3DVWoU5Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QJ1erU2EjXBce91TN7aGMwTzVUyboExPz7I9asApP1cBlfCRqrlh4mDRXGFUKQbVC 2xmOvd1kc1becHOtol6vpq529+9g5Szv+t9bVESsXstMxjCUL1zvyrvEKnT5055PFk 4EkA0pbBQHw2CWShtLCigBmizYAWquRBMybh2qQc= Date: Tue, 18 Aug 2026 17:33:52 +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 12/18] arm64: Implement try_populate_vmemmap_pmd using AF trick Message-ID: References: <20260708031129.3503195-1-jthoughton@google.com> <20260708031129.3503195-13-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-13-jthoughton@google.com> On Wed, Jul 08, 2026 at 03:11:22AM +0000, James Houghton wrote: > This routine is to be used for updating in-use, leaf-level PMDs in the > vmemmap without introducing a window where vmemmap accesses might fault. > > Implementing this on arm64 requires some care: use the same access flag > trick that is used for vmemmap PTE updates. HAFT is not needed and the > TLB flushing routine remains identical, as we are not overwriting a > non-leaf PMD. > > For systems that support BBML2_NOABORT, there is no need to use the AF > trick. This part needs even more text in the Arm ARM. With dropping of the BBML2_NOABORT requirement in patch 13, we are left with the D8.17.2 rules in the Arm ARM (M.c) requiring BBM. I'm not sure we can infer much from the AF=0 caching rules as here we talk about the walk caches. For example, a walk cache memorises the VA to block descriptor translation and that's irrespective of the leaf entry AF bit. If AF=0 and you skip the TLBI, nothing flushes the walk cache which may confuse the CPU when it suddenly sees a table entry where it expected a block one. If it's not critical to the series, I suggest we leave this patch and the next one out for now. -- Catalin