Re: [PATCH 12/18] arm64: Implement try_populate_vmemmap_pmd using AF trick
James Houghton <[email protected]>
| Newsgroups | org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <CADrL8HXZy3HgQeHA6b8TzJX7oWc9goe30sPfP1F5OMUtWLbyBA@mail.gmail.com> |
On Tue, Aug 18, 2026 at 9:34 AM Catalin Marinas <[email protected]> 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.