Re: [PATCH v3 04/18] x86/domain_page: drop redundant create_perdomain_mapping() call

["Roger Pau Monné" <roger@xenproject.org>]

On Wed, Oct 07, 2026 at 11:40:37AM +0100, George Dunlap wrote:
> From: Roger Pau Monné <roger.pau@citrix.com>
> 
> We want to change per-domain mappings to be per-vCPU mappings.  In
> preparation for that, we want to arrange that
> create_perdomain_mapping() work either with a single perdomain area,
> or with a per-vCPU perdomain area.
> 
> One of the current calls in a domain context turns out to be
> unnecessary:
> 
> mapcache_domain_init() pre-plumbs L1 tables over the whole
> inuse/garbage bitmap range (sized for the full MAPCACHE_ENTRIES
> capacity), without populating any data pages.  The plumbing is
> redundant: mapcache_vcpu_init() installs the bitmap pages the domain
> will actually use with populating calls, which allocate any missing
> page-table structure on demand -- and since d->max_vcpus is fixed
> before any vCPU is created, the range those calls cover never grows.
> The pre-plumbed tail beyond it backs virtual addresses that are never
> populated at all.
> 
> In debug builds, and on hosts with memory hotplug or with more memory
> than the PV directmap covers, the call was also what first allocated a
> PV domain's per-domain L3.  Release builds on other hosts already
> allocated it only with the first vCPU.
> 
> Drop the call; now we always allocate only with the first vCPU.
> 
> With the only fallible operation gone, mapcache_domain_init() becomes
> void, and arch_domain_create()'s error handling for it goes away.
> 
> The per-domain-mapping work in mapcache_vcpu_init() stays where it is
> rather than moving into mapcache_domain_init() along with this change,
> ready for a later patch which introduces per-vCPU mapcaches.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8, Claude Code:claude-opus-5-5
> Signed-off-by: George Dunlap <gwd@xenproject.org>

Reviewed-by: Roger Pau Monné <roger@xenproject.org>

Thanks, Roger.