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

Re: [PATCH v3 18/18] x86/spec-ctrl: wire the sparse directmap view into the asi= option



On Thu, Oct 8, 2026 at 8:21 PM Roger Pau Monné <roger@xxxxxxxxxxxxxx> wrote:
>
> On Wed, Oct 07, 2026 at 11:40:51AM +0100, George Dunlap wrote:
> > Let asi= choose which domains run on the sparse view of the directmap,
> > when the hypervisor is built with CONFIG_SPARSE_DIRECTMAP:
> >
> >  * `asi` and `asi=<bool>` enable or disable the sparse view, along with
> >    vCPU-PT, for every domain: HVM and PV guests, and the hardware
> >    domain, PV or PVH.  HVM guests, a PVH hardware domain included, use
> >    the sparse view together with vCPU-PT, which gives them the mapcache
> >    it needs; PV guests all have one.  A PV guest on the sparse view
> >    keeps its domain-wide mapcache and per-domain mappings: the sparse
> >    view separates it from other domains, not its vCPUs from each other.
> >
> >  * `asi=hvm=<bool>`, and new `asi=pv=<bool>` and `asi=dom0=<bool>`, do
> >    the same for HVM or PV guests other than the hardware domain, or for
> >    the hardware domain, whatever its type: `asi=1,dom0=0` leaves the
> >    hardware domain out of ASI altogether.
> >
> >  * A new `asi=directmap=<bool>` selects the sparse view for all domains,
> >    as `asi=vcpu-pt=<bool>` selects vCPU-PT; `vcpu-pt=` alone leaves the
> >    sparse view off.  On a hypervisor built without
> >    CONFIG_SPARSE_DIRECTMAP the forms enabling all features leave the
> >    sparse view off, and `directmap=` is ignored with a warning.  A guest
> >    type the build lacks is ignored, so that the sparse view is not built
> >    for nothing.
> >
> >  * Only one of XPTI and the sparse view are enabled.  Enabled
> >    explicitly, for dom0, domUs or both, XPTI takes precedence: the PV
> >    domains it covers keep the full directmap, and the boot log says
> >    so.  Left to its default, XPTI yields: it is disabled for the PV
> >    domains using the sparse view, with a boot-log warning where it
> >    would otherwise be enabled, as the sparse view does not replace it
> >    yet (it still maps the xenheap and Xen's stacks).  Each domain's
> >    case is settled at its creation.
> >
> > The boot log gains a line with the directmap mode, "sparse" once a
> > sparse view is configured and "full" otherwise, and the "ASI features
> > for ..." lines, one for PV guests now among them, say which domains use
> > the sparse view.
> >
> > Assisted-by: Claude Code:claude-opus-5-5
> > Signed-off-by: George Dunlap <gwd@xxxxxxxxxxxxxx>
> > ---
> > Changes in v3:
> > - New in this version.
> > ---
> >  docs/misc/xen-command-line.pandoc           |  35 +++++-
> >  xen/arch/x86/include/asm/sparse-directmap.h |  28 ++++-
> >  xen/arch/x86/sparse-directmap.c             |   4 +-
> >  xen/arch/x86/spec_ctrl.c                    | 130 ++++++++++++++++++--
> >  4 files changed, 171 insertions(+), 26 deletions(-)
> >
> > diff --git a/docs/misc/xen-command-line.pandoc 
> > b/docs/misc/xen-command-line.pandoc
> > index 785e099c0a..0bbc8ebeff 100644
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -203,7 +203,8 @@ to appropriate auditing by Xen.  Argo is disabled by 
> > default.
> >      buggy or malicious other domain spamming the ring.
> >
> >  ### asi (x86)
> > -> `= List of [ <bool>, hvm=<bool>, vcpu-pt=<bool> | vcpu-pt=hvm=<bool> ]`
> > +> `= List of [ <bool>, {pv,hvm,dom0}=<bool>, directmap=<bool>,
> > +>              vcpu-pt=<bool> | vcpu-pt=hvm=<bool> ]`
> >
> >  > Default: `false`
> >
> > @@ -214,12 +215,16 @@ 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.
> > +The mechanisms currently implemented are `vcpu-pt`, for HVM guests 
> > including
> > +a PVH hardware domain, and `directmap`, for all guests including the 
> > hardware
> > +domain, PV or PVH.  The plain boolean enables or disables both, wherever 
> > they
> > +apply.
> >
> > -* `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>`).
> > +* `pv=`, `hvm=` and `dom0=` enable the features for PV guests or HVM guests
> > +  other than the hardware domain, or for the hardware domain, PV or PVH.  
> > The
> > +  plain boolean does all three: `asi=1,dom0=0` leaves the hardware domain
> > +  out.  The forms naming no guest type (an un-suffixed `vcpu-pt=<bool>`, 
> > and
> > +  `directmap=<bool>`) cover the hardware domain too.
>
> Shouldn't this generic pv, hvm, dom0 set of values go in at the same
> time that `hvm=` is defined?  That would avoid having to re-write the
> paragraph that's been added on this same series.

OK.

> > @@ -514,11 +570,29 @@ static int __init cf_check parse_asi(const char *s)
> >          case 0:
> >          case 1:
> >              opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val;
> > +            set_sparse_dmap(true, true, true, val);
> >              break;
> >
> >          default:
> > -            if ( (val = parse_boolean("hvm", s, ss)) >= 0 )
> > +            if ( (val = parse_boolean("pv", s, ss)) >= 0 )
> > +                set_sparse_dmap(true, false, false, val);
> > +            else if ( (val = parse_boolean("hvm", s, ss)) >= 0 )
> > +            {
> >                  opt_vcpu_pt_hvm = val;
> > +                set_sparse_dmap(false, true, false, val);
> > +            }
> > +            else if ( (val = parse_boolean("dom0", s, ss)) >= 0 )
> > +            {
> > +                opt_vcpu_pt_hwdom = val;
> > +                set_sparse_dmap(false, false, true, val);
> > +            }
> > +            else if ( (val = parse_boolean("directmap", s, ss)) >= 0 )
> > +            {
> > +                /* System-wide: every guest type, the hardware domain too. 
> > */
> > +                set_sparse_dmap(true, true, true, val);
> > +                asi_directmap_ignored = val &&
> > +                                        
> > !IS_ENABLED(CONFIG_SPARSE_DIRECTMAP);
>
> I think we should return error here, rather than print a warning: we
> don't do this for any other command line option that's not parsed
> because the required support has been compiled out.

OK.

Everything else I've either taken, or addressed elsewhere, I think.

 -George



 


Rackspace

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