Re: [PATCH v3 06/18] x86/spec-ctrl: introduce Address Space Isolation command line option

[George Dunlap <gwd@xxxxxxxxxxxxxx>]

On Wed, Oct 7, 2026 at 5:52 PM Roger Pau Monné <roger@xxxxxxxxxxxxxx> wrote:
>
> On Wed, Oct 07, 2026 at 11:40:39AM +0100, George Dunlap wrote:
> > From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> >
> > Introduce the `asi=` command line option, and the
> > opt_vcpu_pt_{hwdom,hvm} knobs plus the per-domain d->arch.vcpu_pt
> > setting they control.  The option is introduced ahead of the
> > functionality it enables, so that the newly added code can be keyed on
> > it from the start; all knobs currently default to off, and enabling any
> > of them taints the boot with a "not functional, development purposes
> > only" warning.
>
> I would possibly avoid using "taint" above, as we have a taint
> mechanism and it might create confusion in the context here.  Using
> ASI doesn't taint the hypervisor.

Ack

> > diff --git a/docs/misc/xen-command-line.pandoc 
> > b/docs/misc/xen-command-line.pandoc
> > index b2c94ae56d..785e099c0a 100644
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -202,6 +202,32 @@ to appropriate auditing by Xen.  Argo is disabled by 
> > default.
> >      This option is disabled by default, to protect domains from a DoS by a
> >      buggy or malicious other domain spamming the ring.
> >
> > +### asi (x86)
>
> AFAICT the sparse direct map series contained support for ARM also, I
> assume this is being dropped from the content pushed (at least in this
> round).  I think we will possibly duplicate the "asi" command line
> option between architectures?

Yes, I think that's the plan; there are a number of other options we
duplicate.  The exact options and what they mean will probably differ
somewhat as well.  No point asking someone trying to use ASI on ARM to
filter out all the stuff about PV, shadow, and XPTI, for instance.

> > +> `= List of [ <bool>, hvm=<bool>, vcpu-pt=<bool> | vcpu-pt=hvm=<bool> ]`
> > +
> > +> Default: `false`
> > +
> > +Offers control over whether the hypervisor will engage in Address Space
> > +Isolation, by not having potentially sensitive information permanently 
> > mapped
> > +in the VMM page-tables.  Using this option might avoid the need to apply
> > +mitigations for certain speculative related attacks, at the cost of mapping
> > +sensitive information on-demand.  It might also offer some protection 
> > against
> > +unmitigated speculation-related attacks.
> > +
> > +The mechanisms currently implemented apply to HVM guests, including a PVH
> > +hardware domain.  PV guests, including a PV hardware domain, are 
> > unaffected.
>
> In the above you mix "guests" and "domains", I would rather use
> "domains" consistently: "... apply to HVM domains, including a PVH
> hardware domain ...".  Same for the instances below.

Ack

> > diff --git a/xen/arch/x86/include/asm/domain.h 
> > b/xen/arch/x86/include/asm/domain.h
> > index c32dec793a..b192c86bc1 100644
> > --- a/xen/arch/x86/include/asm/domain.h
> > +++ b/xen/arch/x86/include/asm/domain.h
> > @@ -477,6 +477,12 @@ struct arch_domain
> >      /* Don't unconditionally inject #GP for unhandled MSRs. */
> >      bool msr_relaxed;
> >
> > +    /*
> > +     * Give each vCPU its own per-domain area (HVM only: each vCPU already
> > +     * runs on its own monitor table).
> > +     */
> > +    bool vcpu_pt;
>
> Do we want to place this inside of an "asi" structure, and possibly
> make it a single bit bitfield?  I think we expect to add more boolean
> ASI related options, so might be nice to have them packed together,
> ie:
>
> /* Fine grained ASI related options. */
> struct {
>     bool vcpu_pt : 1;
> } asi;

Yes, that's nicer.  A tiny bit of churn but worth it I think.

Thanks,
 -George