Re: [PATCH 2/4] xsm/silo: Support hwdom/control domains

[Jason Andryuk <jason.andryuk@xxxxxxx>]

On 2025-06-12 12:56, Jason Andryuk wrote:
> On 2025-06-12 03:52, Jan Beulich wrote:
> > On 11.06.2025 06:20, Jason Andryuk wrote:
> > > On 2025-06-11 09:17, Jan Beulich wrote:
> > > > On 11.06.2025 00:57, Jason Andryuk wrote:
> > > > > In a disaggregated environment, dom0 is split into Control, Hardware,
> > > > > and Xenstore domains, along with domUs.  The is_control_domain() check
> > > > > is not sufficient to handle all these cases.  Add is_priv_domain() to
> > > > > support allowing for the various domains.
> > > > >
> > > > > The purpose of SILO mode is to prevent domUs from interacting with 
> > > > > each
> > > > > other.  But dom0 was allowed to communicate with domUs to provide
> > > > > services.  As the disaggregation of dom0, Control, Hardware and 
> > > > > Xenstore
> > > > > are all service domains that need to communicate with other domains.
> > > > >
> > > > > To provide xenstore connections, the Xenstore domain must be 
> > > > > allowed to
> > > > > connect via grants and event channels.  Xenstore domain must also be
> > > > > allowed to connect to Control and Hardware to provide xenstore to 
> > > > > them.
> > > > Are you suggesting that SILO at present is incompatible with a Xenstore
> > > > domain? silo_mode_dom_check() in its original form has no special
> > > > precautions, after all.
> > > Yes, it is incompatible with the current silo_mode_dom_check().  Only
> > > Control domain is allowed to use grants and event channels with a domU.
> > > A Xenstore domain would be denied.
> > >
> > > Xenstore stubdom only exists for x86 today.  My limited attempts to run
> > > xenstored in an dedicated Xenstore ARM Linux domain have failed.
> > This may want sorting independently first. Once sorted, the requirements
> > here may become more clear.
> HW+XS-> xenstore works
> CTL+XS or XS -> the domain's console just stops.  vCPUs are in Linux cpu 
> idle.  I haven't figured out more.  This required some Linux changes to 
> query the capabilities since XS isn't exposed and ARM assumes initial 
> domain implies HW + CTL.  It's orthogonal to my goals, so I haven't 
> looked too hard.
I got standalone Xenstore working on ARM.  Linux was blocking in 
xs_reset_watches() - the Xenstore domain needs to skip that function 
like xen_initial_domain().
This is with SILO's check as:
static bool is_priv_domain(const struct domain *d)
{
    return evaluate_nospec((d->options & XEN_DOMCTL_CDF_xs_domain) ||
                           d == hardware_domain);
}

Regards,
Jason