Re: [PATCH v2 6/6] xen/arm: Add capabilities to dom0less

[Jason Andryuk <jason.andryuk@xxxxxxx>]

On 2025-04-01 20:03, Stefano Stabellini wrote:
> On Mon, 31 Mar 2025, Jason Andryuk wrote:
> > Add capabilities property to dom0less to allow building a
> > disaggregated system.  Only a single hardware domain and single xenstore
> > domain can be specified.  Multiple control domains are possible.
> >
> > Introduce bootfdt.h to contain these constants.
> >
> > When using the hardware or xenstore capabilities, adjust the grant and
> > event channel limits similar to dom0.
> >
> > For a hardware domain, require an IOMMU and disallow specifying a vpl011
> > console or nr_spis.
> >
> > Signed-off-by: Jason Andryuk <jason.andryuk@xxxxxxx>
> > ---
> > v2:
> > Fix comment style
> > Make DOMAIN_CAPS_* unsigned
> > Remove forced directmap & iommu
> > Require iommu with use of hardware domain
> > Limit to a single xenstore domain
> >
> > There is overlap with hyperlaunch.  The numeric values are the same.
> > Hyperlaunch doesn't expose the values in a public header as done here.
> > Is this to be expected for dom0less?  It seems most of dom0less isn't in
> > a header, but just in docs.
> >
> > Hyperlaunch uses BUILD_CAPS_, but I chose DOMAIN_CAPS_ since there are
> > domain-level capabilities.
> >
> > Only a single xenstore and hardware domain make sense.  Hardware domain
> > receiving all hardware can only have a single domain.
> >
> > For Xenstore, the logic latches the single xs_domid and uses that for
> > all domains.  Also, only a single domain can register for VIRQ_DOM_EXC.
> > ---
> > @@ -1020,6 +1023,40 @@ void __init create_domUs(void)
> >           if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
> >               panic("No more domain IDs available\n");
> >   
> > +        if ( dt_property_read_u32(node, "capabilities", &val) )
> > +        {
> > +            if ( val & ~DOMAIN_CAPS_MASK )
> > +                panic("Invalid capabilities (%"PRIx32")\n", val);
> > +
> > +            if ( val & DOMAIN_CAPS_CONTROL )
> > +                flags |= CDF_privileged;
> > +
> > +            if ( val & DOMAIN_CAPS_HARDWARE )
> > +            {
> > +                if ( hardware_domain )
> > +                    panic("Only 1 hardware domain can be specified! (%pd)\n",
> > +                           hardware_domain);
> > +
> > +                if ( !iommu_enabled )
> > +                    panic("iommu required for dom0less hardware domain\n");
> The panic is OK if "direct-map" is not specified. We need to check for
> direct-map before panic'ing.
Ok, I guess I misunderstood Julien's comment - I thought he wanted to 
require an iommu.  I can re-work it.
!direct-map && !iommu will panic.  Any other combination of direct-map 
and iommu will be allowed.
Hmmm, "passthrough" and "multiboot,device-tree" are essentially ignored 
for hwdom right now.  I'll require them to be unset for hwdom.
Regards,
Jason