Re: [PATCH v2 15/15] x86/hyperlaunch: add capabilities to boot domain

[Jason Andryuk <jason.andryuk@amd.com>]

On 2025-02-04 06:13, Jan Beulich wrote:
> On 26.12.2024 17:57, Daniel P. Smith wrote:
>> Introduce the ability to assign capabilities to a domain via its definition in
>> device tree. The first capability enabled to select is the control domain
>> capability.
> 
> Hmm, and not at the same time another one to select "hardware domain"?

Dan has an un-submitted patch that adds in hardware domain.  Related, I 
was preparing a dom0less patch that adds control, hardware, and xenstore 
capabilities.

I've included it below.  To keep them aligned, it creates a new common 
public header with defines for the capabilities.

Regards,
Jason

commit 5d329e6ef7128a4999b28de6745810c595a7f9e8
Author: Jason Andryuk <jason.andryuk@amd.com>
Date:   Fri Jan 31 14:50:53 2025 -0500

     xen/arm: Add capabilities to dom0less

     Add capabilities property to dom0less to allow building a
     disaggregated system.

     Introduce bootfdt.h to contain these constants.

     Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
     ---
     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.

diff --git a/docs/misc/arm/device-tree/booting.txt 
b/docs/misc/arm/device-tree/booting.txt
index 4346953a71..2cd99f9b79 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -167,6 +167,17 @@ with the following properties:
      Refer to docs/misc/cache_coloring.rst for syntax. This option is 
applicable
      only to Arm64 guests.

+- capabilities
+    Optional.  A bit field of domain capabilities for a disaggregated
+    system.  A traditional dom0 has all all of these capabilities, and a
+    domU has none of them.
+
+    0x1 DOMAIN_CAPS_CONTROL  - A privileged, control domain
+    0x2 DOMAIN_CAPS_HARDWARE - The hardware domain - there can be only 1
+    0x4 DOMAIN_CAPS_XENSTORE - The xenstore domain - there can be only 1
+
+    The default is no capabilities.
+
  - vpl011

      An empty property to enable/disable a virtual pl011 for the guest to
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 9f24463ebd..bb49142d24 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -12,6 +12,7 @@
  #include <xen/sizes.h>
  #include <xen/vmap.h>

+#include <public/bootfdt.h>
  #include <public/io/xs_wire.h>

  #include <asm/arm64/sve.h>
@@ -1236,6 +1237,18 @@ void __init create_domUs(void)
              d_cfg.max_maptrack_frames = val;
          }

+        if ( dt_property_read_u32(node, "capabilities", &val) )
+        {
+            if ( val & ~DOMAIN_CAPS_MASK )
+                panic("invalid capabilities (%"PRIu32") overflow\n", val);
+            if ( val & DOMAIN_CAPS_CONTROL )
+                flags |= CDF_privileged;
+            if ( val & DOMAIN_CAPS_HARDWARE )
+                flags |= CDF_hardware;
+            if ( val & DOMAIN_CAPS_XENSTORE )
+                d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain;
+        }
+
          if ( dt_get_property(node, "sve", &val) )
          {
  #ifdef CONFIG_ARM64_SVE
diff --git a/xen/common/domain.c b/xen/common/domain.c
index c170597410..dbeda908be 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -701,6 +701,10 @@ struct domain *domain_create(domid_t domid,
      /* Sort out our idea of is_hardware_domain(). */
      if ( flags & CDF_hardware || domid == hardware_domid )
      {
+        if ( hardware_domain )
+            panic("Can't set %pd - %pd is already hardware domain\n", d,
+                  hardware_domain);
+
          if ( hardware_domid < 0 || hardware_domid >= 
DOMID_FIRST_RESERVED )
              panic("The value of hardware_dom must be a valid domain 
ID\n");

diff --git a/xen/include/public/bootfdt.h b/xen/include/public/bootfdt.h
new file mode 100644
index 0000000000..4e87aca8ac
--- /dev/null
+++ b/xen/include/public/bootfdt.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Xen Device Tree boot information
+ *
+ * Information for configuring Xen domains created at boot time.
+ */
+
+#ifndef __XEN_PUBLIC_BOOTFDT_H__
+#define __XEN_PUBLIC_BOOTFDT_H__
+
+/* Domain Capabilities specified in the "capabilities" property.  Use of
+ * this property allows splitting up the monolithic dom0 into separate,
+ * less privileged components.  A regular domU has no capabilities
+ * (which is the default if nothing is specified).  A traditional dom0
+ * has all three capabilities.*/
+
+/* Control/Privileged domain capable of affecting other domains. */
+#define DOMAIN_CAPS_CONTROL  (1 << 0)
+/* Hardware domain controlling physical hardware.  Typically providing
+ * backends to other domains.  */
+#define DOMAIN_CAPS_HARDWARE (1 << 1)
+/* Xenstore domain. */
+#define DOMAIN_CAPS_XENSTORE (1 << 2)
+#define DOMAIN_CAPS_MASK     (DOMAIN_CAPS_CONTROL | 
DOMAIN_CAPS_HARDWARE | \
+                              DOMAIN_CAPS_XENSTORE)
+
+#endif /* __XEN_PUBLIC_BOOTFDT_H__ */