[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 05/18] x86/mm: prepare create_perdomain_mapping() for per-vCPU perdomain areas



On Wed, Oct 7, 2026 at 5:32 PM Roger Pau Monné <roger@xxxxxxxxxxxxxx> wrote:
>
> On Wed, Oct 07, 2026 at 11:40:38AM +0100, George Dunlap wrote:
> > From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> >
> > 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.
> >
> > Most of the remaining callers are already in a vCPU context.  This is
> > no accident: the perdomain area has always been laid out in per-vCPU
> > slices -- each vCPU has its own GDT/LDT window, its own
> > COMPAT_ARG_XLAT pages, its own window of mapcache entries -- and each
> > vCPU's slice is set up as that vCPU is created.  For these callers, we
> > just need to change the parameter from a domain pointer to a vCPU
> > pointer.  Once the perdomain area itself becomes per-vCPU, the same
> > calls will populate the owning vCPU's own area rather than slices of a
> > shared one.
> >
> > One exception is the call in hvm_domain_initialise().  An HVM vCPU's
> > monitor table is created during vCPU initialisation, and
> > init_xen_l4_slots() stamps the perdomain slot into it at that point --
> > far earlier than for PV, where the Xen slots are written only once
> > guest page tables are built.  hvm_domain_initialise() therefore had an
> > explicit create_perdomain_mapping() call just to make the perdomain
> > root exist ahead of that.  Move it to arch_vcpu_create(), covering HVM
> > and PV alike.  With a single shared area, the call allocates at most
> > once per domain; but once each vCPU has its own perdomain area, this
> > is the call that will allocate every vCPU's root before any page
> > tables referencing it are built.  vCPU creation is
> > where the call must end up; move it there directly.
>
> I think it's clear from the paragraph above the call must be moved
> there, there's likely no need to re-iterate that fact.
>
> > For PV guests
> > nothing observable changes: the root was already being created during
> > vCPU creation as a side effect (by mapcache_vcpu_init(), or failing
> > that pv_create_gdt_ldt_l1tab()); it now merely becomes explicit.
> >
> > Note that we cannot yet do a parallel movement of
> > free_perdomain_mappings(): the per-domain page-table hierarchy is
> > still a single domain-wide structure shared by all vCPUs, so tearing
> > it down from a per-vCPU path would pull the mappings out from under
> > sibling vCPUs (e.g.  on a partially failed, retryable
> > XEN_DOMCTL_max_vcpus), and vCPU-create error paths can rely on domain
> > destruction to free a partially set up hierarchy.  Teardown will move
> > to vCPU scope only once the structure itself becomes per-vCPU.
>
> Even then - we will still need to support non-ASI (PV domains) not
> using a per-vCPU slot, and hence the call can't be moved as-is just
> when per-vCPU support is available?
>
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > 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@xxxxxxxxxxxxxx>
> > ---
> > Changes in v3:
> > - Rebased onto staging without the GDT/LDT conversions (for the
> >   HVM-only series): the capture parameters stay, as the PV GDT/LDT
> >   stash still uses them.
> >
> > Changes in v2:
> > - Added to the series
> >
> > Changes since the previously posted version:
> > - Keep free_perdomain_mappings() (and hence perdomain teardown)
> >   domain-scoped.
> > - Keep the idle domain without a perdomain area.
> > - Retitle (was: "x86/mm: switch {create,destroy}_perdomain_mapping()
> >   domain parameter to vCPU"); destroy_perdomain_mapping() was switched
> >   in a separate patch.
> > - Split the removal of mapcache_domain_init()'s redundant
> >   create_perdomain_mapping() call into its own (preceding) patch.
> > ---
> >  xen/arch/x86/domain.c         | 10 ++++++++++
> >  xen/arch/x86/domain_page.c    |  6 +++---
> >  xen/arch/x86/hvm/hvm.c        |  5 -----
> >  xen/arch/x86/include/asm/mm.h |  2 +-
> >  xen/arch/x86/mm.c             |  3 ++-
> >  xen/arch/x86/pv/domain.c      |  2 +-
> >  xen/arch/x86/x86_64/mm.c      |  2 +-
> >  7 files changed, 18 insertions(+), 12 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index 85cedc3d03..b670cea52b 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -517,6 +517,16 @@ int arch_vcpu_create(struct vcpu *v)
> >
> >      if ( !is_idle_domain(d) )
> >      {
> > +        /*
> > +         * Make sure the per-domain L3 exists ahead of any consumer (e.g.
> > +         * init_xen_l4_slots() for the HVM monitor tables): with
> > +         * create_perdomain_mapping() taking a vCPU this can no longer be
> > +         * done when creating the domain.
>
> I think the comment here is not very useful - it's not helpful that
> the comment here references the previous position of the call.  It
> only makes sense in the context of this change, but not for someone
> looking at the code after this commit has landed.  I would terminate
> the commit at the ":".
>
> The code itself looks good to me.

Done, thanks.

 -George



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.