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.

!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

Reply via email to