Re: [PATCH v3 12/18] x86/mm: let Xen's page-table walker operate on a given root

[George Dunlap <gwd@xxxxxxxxxxxxxx>]

On Wed, Oct 14, 2026 at 9:08 AM Roger Pau Monné <roger@xxxxxxxxxxxxxx> wrote:
> > > The virtual address space is just part of it, so far
> > > map_pages_to_xen() has been doing global TLB flushes, because all CPUs
> > > used the same page-tables for the Xen slots that map_pages_to_xen()
> > > modifies.  With the change to pass different L4, there's also the
> > > assumption that the Xen slots on those L4 will be different, and hence
> > > not all CPUs might need flushing?
> > >
> > > Maybe I'm thinking ahead too much - but if this is going to be used to
> > > manage the sparse directmap we might want to avoid IPIs to CPUs that
> > > are running with the full directmap when the sparse one is changed,
> > > as those are useless.
> >
> > Yes; changes to both "views" (e.g., map_pages_to_xen()) still need to
> > flush on all CPUs; but changes only to the sparse "view" (e.g.,
> > removing pages on free_xenheap_pages()) could send an IPI only to CPUs
> > with the sparse view running on it.  We could keep a cpumask with
> > which CPUs currently have sparse directmaps loaded, and only IPI
> > those.
> >
> > That said, maintaining the cpumask isn't free; it would cause some
> > cacheline bouncing as vCPUs are scheduled in and out; and since the
> > idle vCPU has the full directmap, even a system with all "normal"
> > domains using the sparse map would still need to update it constantly.
> > Not sure how often free_xenheap_pages() happens, but if it's not very
> > frequent, it might not be worth the cache consistency overhead (and
> > the extra complication).  I'd leave this as a potential future
> > improvement.
>
> Worth adding a TODO comment somewhere about the fact that
> map_pages_to_xen() is likely doing too many flushes when used to
> manage the sparse directmap.  Without going into the more complex
> approach of tracking which CPUs are running with the sparse directmap,
> we could do batch flushes in add_to_sparse_view() for example, as the
> flush could be pulled out of the map_pages_in() loop.

Yes, I've got a bunch of optimizations queued up after key things are
moved out of the xenheap.

 -George