Re: [PATCH 12/18] arm64: Implement try_populate_vmemmap_pmd using AF trick

[James Houghton]

On Tue, Aug 18, 2026 at 9:34 AM Catalin Marinas <catalin.marinas@xxxxxxx> wrote:
>
> 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.

The CPU must still respect block descriptors that become invalid, so
it wouldn't be able to just assume "this is a valid Block descriptor",
right? But I really don't know how implementations actually work here,
so it could be possible that the walk cache could get confused during
Block -> Table transitions without a BBM sequence.

I agree that this should be clarified. I'll try to prepare an HVO-less
description of the required behavior and work with Will to properly
ask about it.

> If it's not critical to the series, I suggest we leave this patch and
> the next one out for now.

I originally included it because I didn't have any machines with
BBML3, but I think I have a Neoverse N3 system which supports BBML3.
:)

I think I'll still include these patches anyway (it's at least useful
to continue to drive the discussion of whether or not the Block ->
Table transition is legal); I'll structure the series such that they
can be easily left off. And I'll note in the cover letter that they
probably ought to be merged separately after more scrutiny.