On Wed, 2 Apr 2025, Jason Andryuk wrote:
> 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.andr...@amd.com>
> > > ---
> > > 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.
There are some subtleties here that it is best to clarify.
Julien asked for the hardware domain not to imply 1:1 memory mapping. If
the hardware domain has memory not mapped 1:1, then the IOMMU is
required. However, a user could still explicitly request the hardware
domain to be 1:1 mapped with the direct-map property, in that case the
IOMMU is optional.
> !direct-map && !iommu will panic. Any other combination of direct-map and
> iommu will be allowed.
I think that's correct
> Hmmm, "passthrough" and "multiboot,device-tree" are essentially ignored for
> hwdom right now. I'll require them to be unset for hwdom.
Good idea
