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

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

On Wed, Oct 07, 2026 at 11:40:39AM +0100, George Dunlap wrote:
> From: Roger Pau Monné <roger.pau@citrix.com>
> 
> 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.

> 
> The mechanisms this option controls apply to HVM domains: an HVM vCPU
> already runs on its own monitor table, so a per-vCPU per-domain area
> needs no work at context switch.  d->arch.vcpu_pt is therefore only
> ever set for HVM domains, a PVH hardware domain included; PV domains,
> a PV hardware domain included, are unaffected.
> 
> The boot log gains "ASI features for ..." lines for Dom0 and HVM
> domains, so hardware-domain-only configurations remain visible.
> 
> Further per-mechanism tokens arrive with their mechanisms in later
> patches.
> 
> 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>
> ---
> Changes in v3:
> - HVM only: drop the PV knob and its interaction with XPTI.  vCPU-PT
>   applies to HVM domains and to a PVH hardware domain; the Dom0 boot
>   log line says None for a PV one.
> 
> Changes in v2:
> - Added to the series
> 
> Changes since the previously posted version:
> - Include the hardware domain in the development warning and the boot
>    log summary.
> - Make the opt_vcpu_pt_* knobs plain booleans preinitialised to false,
>    dropping the late -1 resolution.
> - Documentation: mention possible protection against unmitigated
>    attacks, and state that hvm= does not affect the hardware domain.
> - Rewrite the commit message.
> ---
>  docs/misc/xen-command-line.pandoc    | 26 +++++++++
>  xen/arch/x86/include/asm/domain.h    |  6 +++
>  xen/arch/x86/include/asm/spec_ctrl.h |  2 +
>  xen/arch/x86/spec_ctrl.c             | 79 ++++++++++++++++++++++++++++
>  4 files changed, 113 insertions(+)
> 
> 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?

> +> `= 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.

> +
> +* `hvm=` enables the features for HVM guests other than the hardware domain,
> +  which follows the whole-feature forms (the plain boolean, or an un-suffixed
> +  `vcpu-pt=<bool>`).
> +
> +**WARNING: manual de-selection of enabled options will invalidate any
> +protection offered by the feature.  The fine grained options provided below
> +are meant to be used for debugging purposes only.**
> +
> +* `vcpu-pt` gives each vCPU its own per-domain area: the per-domain slot of
> +  each vCPU's monitor table maps a region private to that vCPU.
> +
>  ### asid (x86)
>  > `= <boolean>`
>  
> 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;

Thanks, Roger.