Re: [PATCH v3 15/18] x86/mm: flush owned pages before reuse with the sparse directmap view

[Roger Pau Monné <roger@xxxxxxxxxxxxxx>]

On Wed, Oct 07, 2026 at 11:40:48AM +0100, George Dunlap wrote:
> Since d7bf1b8ea275 ("x86/mm: limit deferred TLB flushing to PV domain
> support") a page freed by its owner is flushed from TLBs before it is
> handed out again only in builds with PV support, on the premise that PV
> domains, with their (limited) control over the host MMU and over when
> flushes happen, are the only ones to leave stale entries behind.
> 
> Xen's transient mappings of domain pages are another source.  The
> mapcache zaps a slot when it is unmapped but defers the flush: the
> slot's translation can stay in the TLB of the CPU which used it until
> that CPU next flushes, by which time the page may have been freed and
> handed to another domain.  Before "x86/hvm: introduce per-vCPU
> mapcache for vCPU-PT domains", only PV vCPUs use the mapcache, so the
> PV condition covers it.  Now that the vCPUs of an HVM domain with
> per-vCPU page-tables have one as well.
> 
> While the full directmap is loaded in every context, stale transient
> mappings only map what's already mapped in the full directmap.  On the
> sparse view of the directmap, a stale translation of a page handed to
> another domain would keep it reachable from a context which has
> nothing to do with it.

But if it's handed to another domain, then it also hasn't gone through
a free cycle, which is what pg->u.free.need_tlbflush covers?

> So flush owned pages before reuse wherever a sparse view is
> configured, as before d7bf1b8ea275.  In builds without PV support,
> mark_page_free() now also asks a new hook,
> arch_freed_pages_need_tlbflush(), declared with the xenheap hooks the
> sparse view already uses.  x86 answers with sparse_dmap_configured();
> without CONFIG_SPARSE_DIRECTMAP, and on other architectures, the
> answer is no.  Builds with PV support flush as before, and HVM-only
> builds keep d7bf1b8ea275's saving unless a sparse view is configured,
> which nothing does until a later patch.

I think this is not fully correct, in fact I think we need to flush
the map cache on every return to guest, otherwise you risk leaking
contents between processes running on the same vCPU (and by extension
the same physical CPU).

We either need a flush flush before returning to guest, or we need to
invalidate every page that unmapped from the mapcache.

Thanks, Roger.