1. Patchew
  2. Xen
  3. View series

[RFC PATCH] xen/arm: Rebranding dom0less feature

Luca Fancellu posted 1 patch 10 months ago
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20230630091210.3742121-1-luca.fancellu@arm.com
.gitignore                                    |  2 +-
CHANGELOG.md                                  |  2 +
SUPPORT.md                                    |  8 +-
automation/gitlab-ci/test.yaml                | 88 +++++++++----------
...m32.sh => qemu-smoke-hyperlaunch-arm32.sh} |  0
...m64.sh => qemu-smoke-hyperlaunch-arm64.sh} |  2 +-
...arm64.sh => qemu-xtf-hyperlaunch-arm64.sh} |  0
...4.sh => xilinx-smoke-hyperlaunch-arm64.sh} |  2 +-
docs/INDEX                                    |  2 +-
.../{dom0less.pandoc => hyperlaunch.pandoc}   | 33 +++----
docs/misc/arm/device-tree/booting.txt         |  4 +-
docs/misc/efi.pandoc                          | 14 +--
docs/misc/xen-command-line.pandoc             |  2 +-
docs/misc/xenstore-ring.txt                   |  6 +-
tools/helpers/Makefile                        | 20 ++---
...t-dom0less.c => init-hyperlaunch-guests.c} |  4 +-
xen/arch/arm/Kconfig                          |  4 +-
xen/arch/arm/domain_build.c                   | 18 ++--
xen/arch/arm/efi/efi-boot.h                   |  9 +-
xen/arch/arm/include/asm/kernel.h             | 32 +++----
xen/arch/arm/setup.c                          |  8 +-
21 files changed, 132 insertions(+), 128 deletions(-)
rename automation/scripts/{qemu-smoke-dom0less-arm32.sh => qemu-smoke-hyperlaunch-arm32.sh} (100%)
rename automation/scripts/{qemu-smoke-dom0less-arm64.sh => qemu-smoke-hyperlaunch-arm64.sh} (99%)
rename automation/scripts/{qemu-xtf-dom0less-arm64.sh => qemu-xtf-hyperlaunch-arm64.sh} (100%)
rename automation/scripts/{xilinx-smoke-dom0less-arm64.sh => xilinx-smoke-hyperlaunch-arm64.sh} (98%)
rename docs/features/{dom0less.pandoc => hyperlaunch.pandoc} (84%)
rename tools/helpers/{init-dom0less.c => init-hyperlaunch-guests.c} (98%)
[RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Luca Fancellu 10 months ago 
The "dom0less" feature was intended to be the feature where a domU
domain could be launched without the control domain (Dom0)
intervention, however the name seems to suggest that Dom0 cannot
be part of the configuration, while instead it's a possible use case.

To avoid that, rename the "dom0less" configuration with the name
"hyperlaunch", that is less misleading.

Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
---
This is an RFC to get the feeling of the community about the name
change, for now it's everything in one patch just to see how it
will look like, if there is interest on proceeding into it, I can
split in more commit.
Please note that I've left intentionally "dom0less" into the
docs/design/ and CHANGELOG.md
---
---
 .gitignore                                    |  2 +-
 CHANGELOG.md                                  |  2 +
 SUPPORT.md                                    |  8 +-
 automation/gitlab-ci/test.yaml                | 88 +++++++++----------
 ...m32.sh => qemu-smoke-hyperlaunch-arm32.sh} |  0
 ...m64.sh => qemu-smoke-hyperlaunch-arm64.sh} |  2 +-
 ...arm64.sh => qemu-xtf-hyperlaunch-arm64.sh} |  0
 ...4.sh => xilinx-smoke-hyperlaunch-arm64.sh} |  2 +-
 docs/INDEX                                    |  2 +-
 .../{dom0less.pandoc => hyperlaunch.pandoc}   | 33 +++----
 docs/misc/arm/device-tree/booting.txt         |  4 +-
 docs/misc/efi.pandoc                          | 14 +--
 docs/misc/xen-command-line.pandoc             |  2 +-
 docs/misc/xenstore-ring.txt                   |  6 +-
 tools/helpers/Makefile                        | 20 ++---
 ...t-dom0less.c => init-hyperlaunch-guests.c} |  4 +-
 xen/arch/arm/Kconfig                          |  4 +-
 xen/arch/arm/domain_build.c                   | 18 ++--
 xen/arch/arm/efi/efi-boot.h                   |  9 +-
 xen/arch/arm/include/asm/kernel.h             | 32 +++----
 xen/arch/arm/setup.c                          |  8 +-
 21 files changed, 132 insertions(+), 128 deletions(-)
 rename automation/scripts/{qemu-smoke-dom0less-arm32.sh => qemu-smoke-hyperlaunch-arm32.sh} (100%)
 rename automation/scripts/{qemu-smoke-dom0less-arm64.sh => qemu-smoke-hyperlaunch-arm64.sh} (99%)
 rename automation/scripts/{qemu-xtf-dom0less-arm64.sh => qemu-xtf-hyperlaunch-arm64.sh} (100%)
 rename automation/scripts/{xilinx-smoke-dom0less-arm64.sh => xilinx-smoke-hyperlaunch-arm64.sh} (98%)
 rename docs/features/{dom0less.pandoc => hyperlaunch.pandoc} (84%)
 rename tools/helpers/{init-dom0less.c => init-hyperlaunch-guests.c} (98%)

diff --git a/.gitignore b/.gitignore
index c1b73b096893..c9d569247079 100644
--- a/.gitignore
+++ b/.gitignore
@@ -167,7 +167,7 @@ tools/flask/utils/flask-loadpolicy
 tools/flask/utils/flask-setenforce
 tools/flask/utils/flask-set-bool
 tools/flask/utils/flask-label-pci
-tools/helpers/init-dom0less
+tools/helpers/init-hyperlaunch-guests
 tools/helpers/init-xenstore-domain
 tools/helpers/xen-init-dom0
 tools/hotplug/common/hotplugpath.sh
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7d7e0590f8c6..cf01e004b017 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -13,6 +13,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    known user doesn't use it properly, leading to in-guest breakage.
  - The "dom0" option is now supported on Arm and "sve=" sub-option can be used
    to enable dom0 guest to use SVE/SVE2 instructions.
+ - The "dom0less" feature, currently supported only on arm, is renamed to
+   "hyperlaunch".
 
 ### Added
  - On x86, support for features new in Intel Sapphire Rapids CPUs:
diff --git a/SUPPORT.md b/SUPPORT.md
index 35a6249e03b2..fe500652828c 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -342,7 +342,7 @@ Allow sharing of identical pages between guests
 
 ### Static Memory Sharing
 
-Allow to statically set up shared memory on dom0less system,
+Allow to statically set up shared memory on hyperlaunch system,
 enabling domains to do shm-based communication
 
     Status, ARM: Tech Preview
@@ -945,20 +945,20 @@ OVMF firmware implements the UEFI boot protocol.
 
     Status, qemu-xen: Supported
 
-## Dom0less
+## Hyperlaunch
 
 Guest creation from the hypervisor at boot without Dom0 intervention.
 
     Status, ARM: Supported
 
-Memory of dom0less DomUs is not scrubbed at boot when bootscrub=on or
+Memory of hyperlaunch DomUs is not scrubbed at boot when bootscrub=on or
 bootscrub=off are passed as Xen command line parameters. (Memory should
 be scrubbed with bootscrub=idle.) No XSAs will be issues due to
 unscrubbed memory.
 
 ## Static Event Channel
 
-Allow to setup the static event channel on dom0less system, enabling domains
+Allow to setup the static event channel on hyperlaunch system, enabling domains
 to send/receive notifications.
 
     Status, ARM: Tech Preview
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index d5cb238b0ad8..d309c784b643 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -136,18 +136,18 @@ build-each-commit-gcc:
   tags:
     - x86_64
 
-xilinx-smoke-dom0less-arm64-gcc:
+xilinx-smoke-hyperlaunch-arm64-gcc:
   extends: .xilinx-arm64
   script:
-    - ./automation/scripts/xilinx-smoke-dom0less-arm64.sh 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh 2>&1 | tee ${LOGFILE}
   needs:
     - *arm64-test-needs
     - alpine-3.12-gcc-arm64
 
-xilinx-smoke-dom0less-arm64-gcc-gem-passthrough:
+xilinx-smoke-hyperlaunch-arm64-gcc-gem-passthrough:
   extends: .xilinx-arm64
   script:
-    - ./automation/scripts/xilinx-smoke-dom0less-arm64.sh gem-passthrough 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh gem-passthrough 2>&1 | tee ${LOGFILE}
   needs:
     - *arm64-test-needs
     - alpine-3.12-gcc-arm64
@@ -234,98 +234,98 @@ qemu-smoke-dom0-arm64-gcc-debug:
     - *arm64-test-needs
     - alpine-3.12-gcc-debug-arm64
 
-qemu-smoke-dom0less-arm64-gcc:
+qemu-smoke-hyperlaunch-arm64-gcc:
   extends: .qemu-arm64
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh 2>&1 | tee ${LOGFILE}
   needs:
     - *arm64-test-needs
     - alpine-3.12-gcc-arm64
 
-qemu-smoke-dom0less-arm64-gcc-debug:
+qemu-smoke-hyperlaunch-arm64-gcc-debug:
   extends: .qemu-arm64
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh 2>&1 | tee ${LOGFILE}
   needs:
     - *arm64-test-needs
     - alpine-3.12-gcc-debug-arm64
 
-qemu-smoke-dom0less-arm64-gcc-staticmem:
+qemu-smoke-hyperlaunch-arm64-gcc-staticmem:
   extends: .qemu-arm64
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-mem 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-mem 2>&1 | tee ${LOGFILE}
   needs:
     - *arm64-test-needs
     - alpine-3.12-gcc-arm64-staticmem
 
-qemu-smoke-dom0less-arm64-gcc-debug-staticmem:
+qemu-smoke-hyperlaunch-arm64-gcc-debug-staticmem:
   extends: .qemu-arm64
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-mem 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-mem 2>&1 | tee ${LOGFILE}
   needs:
     - *arm64-test-needs
     - alpine-3.12-gcc-debug-arm64-staticmem
 
-qemu-smoke-dom0less-arm64-gcc-staticheap:
+qemu-smoke-hyperlaunch-arm64-gcc-staticheap:
  extends: .qemu-arm64
  script:
-   - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-heap 2>&1 | tee ${LOGFILE}
+   - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-heap 2>&1 | tee ${LOGFILE}
  needs:
    - *arm64-test-needs
    - alpine-3.12-gcc-arm64
 
-qemu-smoke-dom0less-arm64-gcc-debug-staticheap:
+qemu-smoke-hyperlaunch-arm64-gcc-debug-staticheap:
  extends: .qemu-arm64
  script:
-   - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-heap 2>&1 | tee ${LOGFILE}
+   - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-heap 2>&1 | tee ${LOGFILE}
  needs:
    - *arm64-test-needs
    - alpine-3.12-gcc-debug-arm64
 
-qemu-smoke-dom0less-arm64-gcc-static-shared-mem:
+qemu-smoke-hyperlaunch-arm64-gcc-static-shared-mem:
   extends: .qemu-arm64
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-shared-mem 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-shared-mem 2>&1 | tee ${LOGFILE}
   needs:
     - *arm64-test-needs
     - alpine-3.12-gcc-arm64-static-shared-mem
 
-qemu-smoke-dom0less-arm64-gcc-debug-static-shared-mem:
+qemu-smoke-hyperlaunch-arm64-gcc-debug-static-shared-mem:
   extends: .qemu-arm64
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-shared-mem 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-shared-mem 2>&1 | tee ${LOGFILE}
   needs:
     - *arm64-test-needs
     - alpine-3.12-gcc-debug-arm64-static-shared-mem
 
-qemu-smoke-dom0less-arm64-gcc-boot-cpupools:
+qemu-smoke-hyperlaunch-arm64-gcc-boot-cpupools:
   extends: .qemu-arm64
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh boot-cpupools 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh boot-cpupools 2>&1 | tee ${LOGFILE}
   needs:
     - *arm64-test-needs
     - alpine-3.12-gcc-arm64-boot-cpupools
 
-qemu-smoke-dom0less-arm64-gcc-debug-boot-cpupools:
+qemu-smoke-hyperlaunch-arm64-gcc-debug-boot-cpupools:
   extends: .qemu-arm64
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh boot-cpupools 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh boot-cpupools 2>&1 | tee ${LOGFILE}
   needs:
     - *arm64-test-needs
     - alpine-3.12-gcc-debug-arm64-boot-cpupools
 
-qemu-xtf-dom0less-arm64-gcc-hyp-xen-version:
+qemu-xtf-hyperlaunch-arm64-gcc-hyp-xen-version:
   extends: .qemu-arm64
   script:
-    - ./automation/scripts/qemu-xtf-dom0less-arm64.sh hyp-xen-version 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-xtf-hyperlaunch-arm64.sh hyp-xen-version 2>&1 | tee ${LOGFILE}
   needs:
     - alpine-3.12-gcc-arm64
     - qemu-system-aarch64-6.0.0-arm64-export
 
-qemu-xtf-dom0less-arm64-gcc-debug-hyp-xen-version:
+qemu-xtf-hyperlaunch-arm64-gcc-debug-hyp-xen-version:
   extends: .qemu-arm64
   script:
-    - ./automation/scripts/qemu-xtf-dom0less-arm64.sh hyp-xen-version 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-xtf-hyperlaunch-arm64.sh hyp-xen-version 2>&1 | tee ${LOGFILE}
   needs:
     - alpine-3.12-gcc-debug-arm64
     - qemu-system-aarch64-6.0.0-arm64-export
@@ -338,66 +338,66 @@ qemu-smoke-dom0-arm32-gcc:
     - *arm32-test-needs
     - yocto-qemuarm
 
-qemu-smoke-dom0less-arm32-gcc:
+qemu-smoke-hyperlaunch-arm32-gcc:
   extends: .qemu-arm32
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh 2>&1 | tee ${LOGFILE}
   needs:
     - *arm32-test-needs
     - debian-unstable-gcc-arm32
 
-qemu-smoke-dom0less-arm32-gcc-debug:
+qemu-smoke-hyperlaunch-arm32-gcc-debug:
   extends: .qemu-arm32
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh 2>&1 | tee ${LOGFILE}
   needs:
     - *arm32-test-needs
     - debian-unstable-gcc-arm32-debug
 
-qemu-smoke-dom0less-arm32-gcc-staticmem:
+qemu-smoke-hyperlaunch-arm32-gcc-staticmem:
   extends: .qemu-arm32
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh static-mem 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh static-mem 2>&1 | tee ${LOGFILE}
   needs:
     - *arm32-test-needs
     - debian-unstable-gcc-arm32-staticmem
 
-qemu-smoke-dom0less-arm32-gcc-debug-staticmem:
+qemu-smoke-hyperlaunch-arm32-gcc-debug-staticmem:
   extends: .qemu-arm32
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh static-mem 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh static-mem 2>&1 | tee ${LOGFILE}
   needs:
     - *arm32-test-needs
     - debian-unstable-gcc-arm32-debug-staticmem
 
-qemu-smoke-dom0less-arm32-gcc-gzip:
+qemu-smoke-hyperlaunch-arm32-gcc-gzip:
   extends: .qemu-arm32
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh gzip 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh gzip 2>&1 | tee ${LOGFILE}
   needs:
     - *arm32-test-needs
     - debian-unstable-gcc-arm32
 
-qemu-smoke-dom0less-arm32-gcc-debug-gzip:
+qemu-smoke-hyperlaunch-arm32-gcc-debug-gzip:
   extends: .qemu-arm32
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh gzip 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh gzip 2>&1 | tee ${LOGFILE}
   needs:
     - *arm32-test-needs
     - debian-unstable-gcc-arm32-debug
 
-qemu-smoke-dom0less-arm32-gcc-without-dom0:
+qemu-smoke-hyperlaunch-arm32-gcc-without-dom0:
   extends: .qemu-arm32
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh without-dom0 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh without-dom0 2>&1 | tee ${LOGFILE}
   needs:
     - *arm32-test-needs
     - debian-unstable-gcc-arm32
 
-qemu-smoke-dom0less-arm32-gcc-debug-without-dom0:
+qemu-smoke-hyperlaunch-arm32-gcc-debug-without-dom0:
   extends: .qemu-arm32
   script:
-    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh without-dom0 2>&1 | tee ${LOGFILE}
+    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh without-dom0 2>&1 | tee ${LOGFILE}
   needs:
     - *arm32-test-needs
     - debian-unstable-gcc-arm32-debug
diff --git a/automation/scripts/qemu-smoke-dom0less-arm32.sh b/automation/scripts/qemu-smoke-hyperlaunch-arm32.sh
similarity index 100%
rename from automation/scripts/qemu-smoke-dom0less-arm32.sh
rename to automation/scripts/qemu-smoke-hyperlaunch-arm32.sh
diff --git a/automation/scripts/qemu-smoke-dom0less-arm64.sh b/automation/scripts/qemu-smoke-hyperlaunch-arm64.sh
similarity index 99%
rename from automation/scripts/qemu-smoke-dom0less-arm64.sh
rename to automation/scripts/qemu-smoke-hyperlaunch-arm64.sh
index 75f575424a4e..db22cfaa1fd6 100755
--- a/automation/scripts/qemu-smoke-dom0less-arm64.sh
+++ b/automation/scripts/qemu-smoke-hyperlaunch-arm64.sh
@@ -113,7 +113,7 @@ echo "#!/bin/bash
 export LD_LIBRARY_PATH=/usr/local/lib
 bash /etc/init.d/xencommons start
 
-/usr/local/lib/xen/bin/init-dom0less
+/usr/local/lib/xen/bin/init-hyperlaunch-guests
 
 brctl addbr xenbr0
 brctl addif xenbr0 eth0
diff --git a/automation/scripts/qemu-xtf-dom0less-arm64.sh b/automation/scripts/qemu-xtf-hyperlaunch-arm64.sh
similarity index 100%
rename from automation/scripts/qemu-xtf-dom0less-arm64.sh
rename to automation/scripts/qemu-xtf-hyperlaunch-arm64.sh
diff --git a/automation/scripts/xilinx-smoke-dom0less-arm64.sh b/automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh
similarity index 98%
rename from automation/scripts/xilinx-smoke-dom0less-arm64.sh
rename to automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh
index 075305241c8d..35b60720fe08 100755
--- a/automation/scripts/xilinx-smoke-dom0less-arm64.sh
+++ b/automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh
@@ -73,7 +73,7 @@ echo "#!/bin/bash
 export LD_LIBRARY_PATH=/usr/local/lib
 bash /etc/init.d/xencommons start
 
-/usr/local/lib/xen/bin/init-dom0less
+/usr/local/lib/xen/bin/init-hyperlaunch-guests
 
 ${dom0_check}
 " > etc/local.d/xen.start
diff --git a/docs/INDEX b/docs/INDEX
index e673edd75c31..ed3d2e6198ec 100644
--- a/docs/INDEX
+++ b/docs/INDEX
@@ -25,4 +25,4 @@ misc/arm/early-printk		Enabling early printk on ARM
 misc/arm/passthrough		Passthrough a device described in the Device Tree to a guest
 misc/arm/device-tree/booting	Device tree bindings to boot Xen
 misc/arm/device-tree/passthrough	Device tree binding to passthrough a device
-features/dom0less.markdown	Boot multiple domains from Xen in parallel
+features/hyperlaunch.markdown	Boot multiple domains from Xen in parallel
diff --git a/docs/features/dom0less.pandoc b/docs/features/hyperlaunch.pandoc
similarity index 84%
rename from docs/features/dom0less.pandoc
rename to docs/features/hyperlaunch.pandoc
index 725afa055838..a62d534696e3 100644
--- a/docs/features/dom0less.pandoc
+++ b/docs/features/hyperlaunch.pandoc
@@ -1,7 +1,7 @@
-Dom0less
-========
+Hyperlaunch
+===========
 
-"Dom0less" is a set of Xen features that enable the deployment of a Xen
+"Hyperlaunch" is a set of Xen features that enable the deployment of a Xen
 system without an control domain (often referred to as "dom0"). Each
 feature can be used independently from the others, unless otherwise
 stated.
@@ -93,26 +93,26 @@ See docs/misc/arm/device-tree/booting.txt for more information.
 PV Drivers
 ----------
 
-It is possible to use PV drivers with dom0less guests with some
+It is possible to use PV drivers with hyperlaunch started guests with some
 restrictions:
 
-- dom0less domUs that want to use PV drivers support should have the
+- hyperlaunch started domUs that want to use PV drivers support should have the
   "xen,enhanced" property set under their device tree nodes (see
   docs/misc/arm/device-tree/booting.txt)
 - a dom0 must be present (or another domain with enough privileges to
   run the toolstack)
-- after dom0 is booted, the utility "init-dom0less" must be run
-- do not run "init-dom0less" while creating other guests with xl
+- after dom0 is booted, the utility "init-hyperlaunch-guests" must be run
+- do not run "init-hyperlaunch-guests" while creating other guests with xl
 
-After the execution of init-dom0less, it is possible to use "xl" to
-hotplug PV drivers to dom0less guests. E.g. xl network-attach domU.
+After the execution of init-hyperlaunch-guests, it is possible to use "xl" to
+hotplug PV drivers to hyperlaunch started guests. E.g. xl network-attach domU.
 
 The implementation works as follows:
-- Xen allocates the xenstore event channel for each dom0less domU that
-  has the "xen,enhanced" property, and sets HVM_PARAM_STORE_EVTCHN
+- Xen allocates the xenstore event channel for each hyperlaunch started domU
+  that has the "xen,enhanced" property, and sets HVM_PARAM_STORE_EVTCHN
 - Xen does *not* allocate the xenstore page and sets HVM_PARAM_STORE_PFN
   to ~0ULL (invalid)
-- Dom0less domU kernels check that HVM_PARAM_STORE_PFN is set to invalid
+- Hyperlaunch started domU kernels check that HVM_PARAM_STORE_PFN is set to invalid
     - Old kernels will continue without xenstore support (Note: some old
       buggy kernels might crash because they don't check the validity of
       HVM_PARAM_STORE_PFN before using it! Disable "xen,enhanced" in
@@ -120,7 +120,7 @@ The implementation works as follows:
     - New kernels will wait for a notification on the xenstore event
       channel (HVM_PARAM_STORE_EVTCHN) before continuing with the
       initialization
-- Once dom0 is booted, init-dom0less is executed:
+- Once dom0 is booted, init-hyperlaunch-guests is executed:
     - it allocates the xenstore shared page and sets HVM_PARAM_STORE_PFN
     - it calls xs_introduce_domain
 - Xenstored notices the new domain, initializes interfaces as usual, and
@@ -159,12 +159,13 @@ Notes
 -----
 
 - 'xl console' command will not attach to the domain's console in case
-  of dom0less. DomU are domains created by Xen (similar to Dom0) and
-  therefore they are all managed by Xen and some of the commands may not work.
+  of hyperlaunch started guests. DomU are domains created by Xen (similar to
+  Dom0) and therefore they are all managed by Xen and some of the commands may
+  not work.
 
   A user is allowed to configure the key sequence to switch input.
   Pressing the Xen "conswitch" (Ctrl-A by default) three times
-  switches input in case of dom0less mode.
+  switches input in case of hyperlaunch mode.
 
 - Domains created by Xen will have no name at boot. Domain-0 has a name
   thanks to the helper xen-init-dom0 called at boot by the initscript.
diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index bbd955e9c2f6..10ec1910a75a 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -572,8 +572,8 @@ Static Shared Memory
 ====================
 
 The static shared memory device tree nodes allow users to statically set up
-shared memory on dom0less system, enabling domains to do shm-based
-communication.
+shared memory on Hyperlaunch started guests system, enabling domains to do
+shm-based communication.
 
 - compatible
 
diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
index 11c1ac334600..d15cb87b49d1 100644
--- a/docs/misc/efi.pandoc
+++ b/docs/misc/efi.pandoc
@@ -194,12 +194,12 @@ chosen {
 	};
 }
 
-## UEFI boot and dom0less on ARM
+## UEFI boot and Hyperlaunch on ARM
 
-Dom0less feature is supported by ARM and it is possible to use it when Xen is
+Hyperlaunch feature is supported by ARM and it is possible to use it when Xen is
 started as an EFI application.
 The way to specify the domU domains is by Device Tree as specified in the
-[dom0less](dom0less.html) documentation page under the "Device Tree
+[Hyperlaunch](hyperlaunch.html) documentation page under the "Device Tree
 configuration" section, but instead of declaring the reg property in the boot
 module, the user must specify the "xen,uefi-binary" property containing the name
 of the binary file that has to be loaded in memory.
@@ -236,7 +236,7 @@ domU1 {
 These are the different ways to boot a Xen system from UEFI:
 
  - Boot Xen and Dom0 (minimum required)
- - Boot Xen and DomU(s) (true dom0less, only on ARM)
+ - Boot Xen and DomU(s) (only on ARM)
  - Boot Xen, Dom0 and DomU(s) (only on ARM)
 
 ### Boot Xen and Dom0
@@ -247,7 +247,7 @@ example above.
 ### Boot Xen and DomU(s)
 
 This configuration needs the domU domain(s) specified in the /chosen node,
-examples of how to do that are provided by the documentation about dom0less
+examples of how to do that are provided by the documentation about Hyperlaunch
 and the example above shows how to use the "xen,uefi-binary" property to use the
 UEFI stub for module loading.
 When adding DomU modules to device tree, also add the property
@@ -258,7 +258,7 @@ can specify the Xen boot arguments in the configuration file with the "options="
 keyword or in the device tree with the "xen,xen-bootargs" property, but be
 aware that the Xen configuration file value has a precedence over the DT value.
 
-Example 1 of how to boot a true dom0less configuration:
+Example 1 of how to boot an Hyperlaunch configuration with only domU(s):
 
 Xen configuration file: skipped.
 
@@ -301,7 +301,7 @@ chosen {
 };
 ```
 
-Example 2 of how to boot a true dom0less configuration:
+Example 2 of how to boot an Hyperlaunch configuration with only domU(s):
 
 Xen configuration file:
 
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 4060ebdc5d76..35d7c9821963 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1156,7 +1156,7 @@ to use the default.
 > Default : `true`
 
 Flag to enable or disable support for extended regions for Dom0 and
-Dom0less DomUs.
+Hyperlaunch started DomUs.
 
 Extended regions are ranges of unused address space exposed to the guest
 as "safe to use" for special memory mappings. Disable if your board
diff --git a/docs/misc/xenstore-ring.txt b/docs/misc/xenstore-ring.txt
index dbc7335e24b8..f84dedd8016e 100644
--- a/docs/misc/xenstore-ring.txt
+++ b/docs/misc/xenstore-ring.txt
@@ -115,9 +115,9 @@ and reconnect is in progress") and signalling the event channel.
 The guest must now ignore all fields except the Connection state and
 wait for it to be set to 0 ("Ring is connected").
 
-In certain circumstances (e.g. dom0less guests with PV drivers support)
-it is possible for the guest to find the Connection state already set to
-1 by someone else during xenstore initialization. In that case, like in
+In certain circumstances (e.g. Hyperlaunch started guests with PV drivers
+support) it is possible for the guest to find the Connection state already set
+to 1 by someone else during xenstore initialization. In that case, like in
 the previous case, the guest must ignore all fields except the
 Connection state and wait for it to be set to 0 before proceeding.
 
diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
index 09590eb5b6f0..332ab47da318 100644
--- a/tools/helpers/Makefile
+++ b/tools/helpers/Makefile
@@ -11,7 +11,7 @@ ifeq ($(CONFIG_X86),y)
 TARGETS += init-xenstore-domain
 endif
 ifeq ($(CONFIG_ARM),y)
-TARGETS += init-dom0less
+TARGETS += init-hyperlaunch-guests
 endif
 endif
 
@@ -31,13 +31,13 @@ $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h
 init-xenstore-domain: LDLIBS += $(call xenlibs-ldlibs,toollog store ctrl guest light)
 
-INIT_DOM0LESS_OBJS = init-dom0less.o init-dom-json.o
-$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
-$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenstore)
-$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenlight)
-$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
-$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenevtchn)
-init-dom0less: LDLIBS += $(call xenlibs-ldlibs,ctrl evtchn toollog store light guest foreignmemory)
+INIT_HYPERLAUNCH_OBJS = init-hyperlaunch-guests.o init-dom-json.o
+$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
+$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxenstore)
+$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxenlight)
+$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
+$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxenevtchn)
+init-hyperlaunch-guests: LDLIBS += $(call xenlibs-ldlibs,ctrl evtchn toollog store light guest foreignmemory)
 
 .PHONY: all
 all: $(TARGETS)
@@ -48,8 +48,8 @@ xen-init-dom0: $(XEN_INIT_DOM0_OBJS)
 init-xenstore-domain: $(INIT_XENSTORE_DOMAIN_OBJS)
 	$(CC) $(LDFLAGS) -o $@ $(INIT_XENSTORE_DOMAIN_OBJS) $(LDLIBS) $(APPEND_LDFLAGS)
 
-init-dom0less: $(INIT_DOM0LESS_OBJS)
-	$(CC) $(LDFLAGS) -o $@ $(INIT_DOM0LESS_OBJS) $(LDLIBS) $(APPEND_LDFLAGS)
+init-hyperlaunch-guests: $(INIT_HYPERLAUNCH_OBJS)
+	$(CC) $(LDFLAGS) -o $@ $(INIT_HYPERLAUNCH_OBJS) $(LDLIBS) $(APPEND_LDFLAGS)
 
 .PHONY: install
 install: all
diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-hyperlaunch-guests.c
similarity index 98%
rename from tools/helpers/init-dom0less.c
rename to tools/helpers/init-hyperlaunch-guests.c
index fee93459c4b9..c786a5fd37b2 100644
--- a/tools/helpers/init-dom0less.c
+++ b/tools/helpers/init-hyperlaunch-guests.c
@@ -129,7 +129,7 @@ static int create_xenstore(struct xs_handle *xsh,
     rc = snprintf(id_str, STR_MAX_LENGTH, "%u", domid);
     if (rc < 0 || rc >= STR_MAX_LENGTH)
         return rc;
-    rc = snprintf(dom_name_str, STR_MAX_LENGTH, "dom0less-%u", domid);
+    rc = snprintf(dom_name_str, STR_MAX_LENGTH, "hyperlaunch-%u", domid);
     if (rc < 0 || rc >= STR_MAX_LENGTH)
         return rc;
     rc = snprintf(uuid_str, STR_MAX_LENGTH, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
@@ -232,7 +232,7 @@ static int init_domain(struct xs_handle *xsh,
     int rc;
     struct xenstore_domain_interface *intf;
 
-    printf("Init dom0less domain: %u\n", info->domid);
+    printf("Init hyperlaunch domain: %u\n", info->domid);
 
     rc = xc_hvm_param_get(xch, info->domid, HVM_PARAM_STORE_EVTCHN,
                           &xenstore_evtchn);
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 61e581b8c2b0..c5cb8f28011a 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -179,10 +179,10 @@ config TEE
 source "arch/arm/tee/Kconfig"
 
 config STATIC_SHM
-	bool "Statically shared memory on a dom0less system" if UNSUPPORTED
+	bool "Statically shared memory on an Hyperlaunch system" if UNSUPPORTED
 	depends on STATIC_MEMORY
 	help
-	  This option enables statically shared memory on a dom0less system.
+	  This option enables statically shared memory on an Hyperlaunch system.
 
 endmenu
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d0d6be922db1..897e1f2de39e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -42,7 +42,7 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
 /*
  * If true, the extended regions support is enabled for dom0 and
- * dom0less domUs.
+ * Hyperlaunch started domUs.
  */
 static bool __initdata opt_ext_regions = true;
 boolean_param("ext_regions", opt_ext_regions);
@@ -3347,7 +3347,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
             goto err;
     }
 
-    if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS )
+    if ( kinfo->hyperlaunch_feature & HYPERLAUNCH_ENHANCED_NO_XS )
     {
         ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
         if ( ret )
@@ -3810,7 +3810,7 @@ static int __init construct_domU(struct domain *d,
                                  const struct dt_device_node *node)
 {
     struct kernel_info kinfo = {};
-    const char *dom0less_enhanced;
+    const char *hyperlaunch_enhanced;
     int rc;
     u64 mem;
     u32 p2m_mem_mb;
@@ -3841,18 +3841,18 @@ static int __init construct_domU(struct domain *d,
 
     kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
 
-    rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
+    rc = dt_property_read_string(node, "xen,enhanced", &hyperlaunch_enhanced);
     if ( rc == -EILSEQ ||
          rc == -ENODATA ||
-         (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) )
+         (rc == 0 && !strcmp(hyperlaunch_enhanced, "enabled")) )
     {
         if ( hardware_domain )
-            kinfo.dom0less_feature = DOM0LESS_ENHANCED;
+            kinfo.hyperlaunch_feature = HYPERLAUNCH_ENHANCED;
         else
             panic("At the moment, Xenstore support requires dom0 to be present\n");
     }
-    else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") )
-        kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS;
+    else if ( rc == 0 && !strcmp(hyperlaunch_enhanced, "no-xenstore") )
+        kinfo.hyperlaunch_feature = HYPERLAUNCH_ENHANCED_NO_XS;
 
     if ( vcpu_create(d, 0) == NULL )
         return -ENOMEM;
@@ -3902,7 +3902,7 @@ static int __init construct_domU(struct domain *d,
     if ( rc < 0 )
         return rc;
 
-    if ( kinfo.dom0less_feature & DOM0LESS_XENSTORE )
+    if ( kinfo.hyperlaunch_feature & HYPERLAUNCH_XENSTORE )
     {
         ASSERT(hardware_domain);
         rc = alloc_xenstore_evtchn(d);
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index bb64925d708c..cccf90817279 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -807,9 +807,9 @@ static int __init handle_module_node(const EFI_LOADED_IMAGE *loaded_image,
  * in the DT.
  * Returns number of multiboot,module found or negative number on error.
  */
-static int __init handle_dom0less_domain_node(const EFI_LOADED_IMAGE *loaded_image,
-                                              EFI_FILE_HANDLE *dir_handle,
-                                              int domain_node)
+static int __init
+handle_hyperlaunch_domain_node(const EFI_LOADED_IMAGE *loaded_image,
+                               EFI_FILE_HANDLE *dir_handle, int domain_node)
 {
     int module_node, addr_cells, size_cells, len;
     const struct fdt_property *prop;
@@ -879,7 +879,8 @@ static int __init efi_check_dt_boot(const EFI_LOADED_IMAGE *loaded_image)
         if ( !fdt_node_check_compatible(fdt, node, "xen,domain") )
         {
             /* Found a node with compatible xen,domain; handle this node. */
-            ret = handle_dom0less_domain_node(loaded_image, &dir_handle, node);
+            ret = handle_hyperlaunch_domain_node(loaded_image, &dir_handle,
+                                                 node);
             if ( ret < 0 )
                 return ERROR_DT_MODULE_DOMU;
         }
diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
index 4617cdc83bac..042e250e172a 100644
--- a/xen/arch/arm/include/asm/kernel.h
+++ b/xen/arch/arm/include/asm/kernel.h
@@ -10,23 +10,23 @@
 #include <asm/setup.h>
 
 /*
- * List of possible features for dom0less domUs
+ * List of possible features for Hyperlaunch started domUs
  *
- * DOM0LESS_ENHANCED_NO_XS: Notify the OS it is running on top of Xen. All the
- *                          default features (excluding Xenstore) will be
- *                          available. Note that an OS *must* not rely on the
- *                          availability of Xen features if this is not set.
- * DOM0LESS_XENSTORE:       Xenstore will be enabled for the VM. This feature
- *                          can't be enabled without the
- *                          DOM0LESS_ENHANCED_NO_XS.
- * DOM0LESS_ENHANCED:       Notify the OS it is running on top of Xen. All the
- *                          default features (including Xenstore) will be
- *                          available. Note that an OS *must* not rely on the
- *                          availability of Xen features if this is not set.
+ * HYPERLAUNCH_ENHANCED_NO_XS: Notify the OS it is running on top of Xen. All
+ *                             the default features (excluding Xenstore) will be
+ *                             available. Note that an OS *must* not rely on the
+ *                             availability of Xen features if this is not set.
+ * HYPERLAUNCH_XENSTORE:       Xenstore will be enabled for the VM. This feature
+ *                             can't be enabled without the
+ *                             HYPERLAUNCH_ENHANCED_NO_XS.
+ * HYPERLAUNCH_ENHANCED:       Notify the OS it is running on top of Xen. All
+ *                             the default features (including Xenstore) will be
+ *                             available. Note that an OS *must* not rely on the
+ *                             availability of Xen features if this is not set.
  */
-#define DOM0LESS_ENHANCED_NO_XS  BIT(0, U)
-#define DOM0LESS_XENSTORE        BIT(1, U)
-#define DOM0LESS_ENHANCED        (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE)
+#define HYPERLAUNCH_ENHANCED_NO_XS  BIT(0, U)
+#define HYPERLAUNCH_XENSTORE        BIT(1, U)
+#define HYPERLAUNCH_ENHANCED        (HYPERLAUNCH_ENHANCED_NO_XS | HYPERLAUNCH_XENSTORE)
 
 struct kernel_info {
 #ifdef CONFIG_ARM_64
@@ -57,7 +57,7 @@ struct kernel_info {
     bool vpl011;
 
     /* Enable/Disable PV drivers interfaces */
-    uint16_t dom0less_feature;
+    uint16_t hyperlaunch_feature;
 
     /* GIC phandle */
     uint32_t phandle_gic;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index bbf72b69aae6..955c6b9e2e9e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -1041,7 +1041,7 @@ static void __init setup_mm(void)
 }
 #endif
 
-static bool __init is_dom0less_mode(void)
+static bool __init is_hyperlaunch_mode(void)
 {
     struct bootmodules *mods = &bootinfo.modules;
     struct bootmodule *mod;
@@ -1068,7 +1068,7 @@ static bool __init is_dom0less_mode(void)
 
     /*
      * If there is no dom0 kernel but at least one domU, then we are in
-     * dom0less mode
+     * Hyperlaunch mode
      */
     return ( !dom0found && domUfound );
 }
@@ -1242,10 +1242,10 @@ void __init start_xen(unsigned long boot_phys_offset,
     enable_cpu_features();
 
     /* Create initial domain 0. */
-    if ( !is_dom0less_mode() )
+    if ( !is_hyperlaunch_mode() )
         create_dom0();
     else
-        printk(XENLOG_INFO "Xen dom0less mode detected\n");
+        printk(XENLOG_INFO "Xen Hyperlaunch mode detected\n");
 
     if ( acpi_disabled )
     {
-- 
2.34.1
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Stefano Stabellini 10 months ago 
On Fri, 29 Jun 2023, Luca Fancellu wrote:
> The "dom0less" feature was intended to be the feature where a domU
> domain could be launched without the control domain (Dom0)
> intervention, however the name seems to suggest that Dom0 cannot
> be part of the configuration, while instead it's a possible use case.
> 
> To avoid that, rename the "dom0less" configuration with the name
> "hyperlaunch", that is less misleading.
> 
> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>

I tested this patch on gitlab-ci and everything works as expected. I
also confirmed that there are no other mentions of "dom0less", except
for docs/designs/launch/hyperlaunch*.

I think this patch could go in as-is and
docs/designs/launch/hyperlaunch* could be fixed later, because the
changes here are mechanical, while docs/designs/launch/hyperlaunch* will
need rewording.

So:

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
> This is an RFC to get the feeling of the community about the name
> change, for now it's everything in one patch just to see how it
> will look like, if there is interest on proceeding into it, I can
> split in more commit.
> Please note that I've left intentionally "dom0less" into the
> docs/design/ and CHANGELOG.md
> ---
> ---
>  .gitignore                                    |  2 +-
>  CHANGELOG.md                                  |  2 +
>  SUPPORT.md                                    |  8 +-
>  automation/gitlab-ci/test.yaml                | 88 +++++++++----------
>  ...m32.sh => qemu-smoke-hyperlaunch-arm32.sh} |  0
>  ...m64.sh => qemu-smoke-hyperlaunch-arm64.sh} |  2 +-
>  ...arm64.sh => qemu-xtf-hyperlaunch-arm64.sh} |  0
>  ...4.sh => xilinx-smoke-hyperlaunch-arm64.sh} |  2 +-
>  docs/INDEX                                    |  2 +-
>  .../{dom0less.pandoc => hyperlaunch.pandoc}   | 33 +++----
>  docs/misc/arm/device-tree/booting.txt         |  4 +-
>  docs/misc/efi.pandoc                          | 14 +--
>  docs/misc/xen-command-line.pandoc             |  2 +-
>  docs/misc/xenstore-ring.txt                   |  6 +-
>  tools/helpers/Makefile                        | 20 ++---
>  ...t-dom0less.c => init-hyperlaunch-guests.c} |  4 +-
>  xen/arch/arm/Kconfig                          |  4 +-
>  xen/arch/arm/domain_build.c                   | 18 ++--
>  xen/arch/arm/efi/efi-boot.h                   |  9 +-
>  xen/arch/arm/include/asm/kernel.h             | 32 +++----
>  xen/arch/arm/setup.c                          |  8 +-
>  21 files changed, 132 insertions(+), 128 deletions(-)
>  rename automation/scripts/{qemu-smoke-dom0less-arm32.sh => qemu-smoke-hyperlaunch-arm32.sh} (100%)
>  rename automation/scripts/{qemu-smoke-dom0less-arm64.sh => qemu-smoke-hyperlaunch-arm64.sh} (99%)
>  rename automation/scripts/{qemu-xtf-dom0less-arm64.sh => qemu-xtf-hyperlaunch-arm64.sh} (100%)
>  rename automation/scripts/{xilinx-smoke-dom0less-arm64.sh => xilinx-smoke-hyperlaunch-arm64.sh} (98%)
>  rename docs/features/{dom0less.pandoc => hyperlaunch.pandoc} (84%)
>  rename tools/helpers/{init-dom0less.c => init-hyperlaunch-guests.c} (98%)
> 
> diff --git a/.gitignore b/.gitignore
> index c1b73b096893..c9d569247079 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -167,7 +167,7 @@ tools/flask/utils/flask-loadpolicy
>  tools/flask/utils/flask-setenforce
>  tools/flask/utils/flask-set-bool
>  tools/flask/utils/flask-label-pci
> -tools/helpers/init-dom0less
> +tools/helpers/init-hyperlaunch-guests
>  tools/helpers/init-xenstore-domain
>  tools/helpers/xen-init-dom0
>  tools/hotplug/common/hotplugpath.sh
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 7d7e0590f8c6..cf01e004b017 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -13,6 +13,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>     known user doesn't use it properly, leading to in-guest breakage.
>   - The "dom0" option is now supported on Arm and "sve=" sub-option can be used
>     to enable dom0 guest to use SVE/SVE2 instructions.
> + - The "dom0less" feature, currently supported only on arm, is renamed to
> +   "hyperlaunch".
>  
>  ### Added
>   - On x86, support for features new in Intel Sapphire Rapids CPUs:
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 35a6249e03b2..fe500652828c 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -342,7 +342,7 @@ Allow sharing of identical pages between guests
>  
>  ### Static Memory Sharing
>  
> -Allow to statically set up shared memory on dom0less system,
> +Allow to statically set up shared memory on hyperlaunch system,
>  enabling domains to do shm-based communication
>  
>      Status, ARM: Tech Preview
> @@ -945,20 +945,20 @@ OVMF firmware implements the UEFI boot protocol.
>  
>      Status, qemu-xen: Supported
>  
> -## Dom0less
> +## Hyperlaunch
>  
>  Guest creation from the hypervisor at boot without Dom0 intervention.
>  
>      Status, ARM: Supported
>  
> -Memory of dom0less DomUs is not scrubbed at boot when bootscrub=on or
> +Memory of hyperlaunch DomUs is not scrubbed at boot when bootscrub=on or
>  bootscrub=off are passed as Xen command line parameters. (Memory should
>  be scrubbed with bootscrub=idle.) No XSAs will be issues due to
>  unscrubbed memory.
>  
>  ## Static Event Channel
>  
> -Allow to setup the static event channel on dom0less system, enabling domains
> +Allow to setup the static event channel on hyperlaunch system, enabling domains
>  to send/receive notifications.
>  
>      Status, ARM: Tech Preview
> diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
> index d5cb238b0ad8..d309c784b643 100644
> --- a/automation/gitlab-ci/test.yaml
> +++ b/automation/gitlab-ci/test.yaml
> @@ -136,18 +136,18 @@ build-each-commit-gcc:
>    tags:
>      - x86_64
>  
> -xilinx-smoke-dom0less-arm64-gcc:
> +xilinx-smoke-hyperlaunch-arm64-gcc:
>    extends: .xilinx-arm64
>    script:
> -    - ./automation/scripts/xilinx-smoke-dom0less-arm64.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm64-test-needs
>      - alpine-3.12-gcc-arm64
>  
> -xilinx-smoke-dom0less-arm64-gcc-gem-passthrough:
> +xilinx-smoke-hyperlaunch-arm64-gcc-gem-passthrough:
>    extends: .xilinx-arm64
>    script:
> -    - ./automation/scripts/xilinx-smoke-dom0less-arm64.sh gem-passthrough 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh gem-passthrough 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm64-test-needs
>      - alpine-3.12-gcc-arm64
> @@ -234,98 +234,98 @@ qemu-smoke-dom0-arm64-gcc-debug:
>      - *arm64-test-needs
>      - alpine-3.12-gcc-debug-arm64
>  
> -qemu-smoke-dom0less-arm64-gcc:
> +qemu-smoke-hyperlaunch-arm64-gcc:
>    extends: .qemu-arm64
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm64-test-needs
>      - alpine-3.12-gcc-arm64
>  
> -qemu-smoke-dom0less-arm64-gcc-debug:
> +qemu-smoke-hyperlaunch-arm64-gcc-debug:
>    extends: .qemu-arm64
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm64-test-needs
>      - alpine-3.12-gcc-debug-arm64
>  
> -qemu-smoke-dom0less-arm64-gcc-staticmem:
> +qemu-smoke-hyperlaunch-arm64-gcc-staticmem:
>    extends: .qemu-arm64
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-mem 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-mem 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm64-test-needs
>      - alpine-3.12-gcc-arm64-staticmem
>  
> -qemu-smoke-dom0less-arm64-gcc-debug-staticmem:
> +qemu-smoke-hyperlaunch-arm64-gcc-debug-staticmem:
>    extends: .qemu-arm64
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-mem 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-mem 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm64-test-needs
>      - alpine-3.12-gcc-debug-arm64-staticmem
>  
> -qemu-smoke-dom0less-arm64-gcc-staticheap:
> +qemu-smoke-hyperlaunch-arm64-gcc-staticheap:
>   extends: .qemu-arm64
>   script:
> -   - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-heap 2>&1 | tee ${LOGFILE}
> +   - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-heap 2>&1 | tee ${LOGFILE}
>   needs:
>     - *arm64-test-needs
>     - alpine-3.12-gcc-arm64
>  
> -qemu-smoke-dom0less-arm64-gcc-debug-staticheap:
> +qemu-smoke-hyperlaunch-arm64-gcc-debug-staticheap:
>   extends: .qemu-arm64
>   script:
> -   - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-heap 2>&1 | tee ${LOGFILE}
> +   - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-heap 2>&1 | tee ${LOGFILE}
>   needs:
>     - *arm64-test-needs
>     - alpine-3.12-gcc-debug-arm64
>  
> -qemu-smoke-dom0less-arm64-gcc-static-shared-mem:
> +qemu-smoke-hyperlaunch-arm64-gcc-static-shared-mem:
>    extends: .qemu-arm64
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-shared-mem 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-shared-mem 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm64-test-needs
>      - alpine-3.12-gcc-arm64-static-shared-mem
>  
> -qemu-smoke-dom0less-arm64-gcc-debug-static-shared-mem:
> +qemu-smoke-hyperlaunch-arm64-gcc-debug-static-shared-mem:
>    extends: .qemu-arm64
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-shared-mem 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-shared-mem 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm64-test-needs
>      - alpine-3.12-gcc-debug-arm64-static-shared-mem
>  
> -qemu-smoke-dom0less-arm64-gcc-boot-cpupools:
> +qemu-smoke-hyperlaunch-arm64-gcc-boot-cpupools:
>    extends: .qemu-arm64
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh boot-cpupools 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh boot-cpupools 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm64-test-needs
>      - alpine-3.12-gcc-arm64-boot-cpupools
>  
> -qemu-smoke-dom0less-arm64-gcc-debug-boot-cpupools:
> +qemu-smoke-hyperlaunch-arm64-gcc-debug-boot-cpupools:
>    extends: .qemu-arm64
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh boot-cpupools 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh boot-cpupools 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm64-test-needs
>      - alpine-3.12-gcc-debug-arm64-boot-cpupools
>  
> -qemu-xtf-dom0less-arm64-gcc-hyp-xen-version:
> +qemu-xtf-hyperlaunch-arm64-gcc-hyp-xen-version:
>    extends: .qemu-arm64
>    script:
> -    - ./automation/scripts/qemu-xtf-dom0less-arm64.sh hyp-xen-version 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-xtf-hyperlaunch-arm64.sh hyp-xen-version 2>&1 | tee ${LOGFILE}
>    needs:
>      - alpine-3.12-gcc-arm64
>      - qemu-system-aarch64-6.0.0-arm64-export
>  
> -qemu-xtf-dom0less-arm64-gcc-debug-hyp-xen-version:
> +qemu-xtf-hyperlaunch-arm64-gcc-debug-hyp-xen-version:
>    extends: .qemu-arm64
>    script:
> -    - ./automation/scripts/qemu-xtf-dom0less-arm64.sh hyp-xen-version 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-xtf-hyperlaunch-arm64.sh hyp-xen-version 2>&1 | tee ${LOGFILE}
>    needs:
>      - alpine-3.12-gcc-debug-arm64
>      - qemu-system-aarch64-6.0.0-arm64-export
> @@ -338,66 +338,66 @@ qemu-smoke-dom0-arm32-gcc:
>      - *arm32-test-needs
>      - yocto-qemuarm
>  
> -qemu-smoke-dom0less-arm32-gcc:
> +qemu-smoke-hyperlaunch-arm32-gcc:
>    extends: .qemu-arm32
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm32-test-needs
>      - debian-unstable-gcc-arm32
>  
> -qemu-smoke-dom0less-arm32-gcc-debug:
> +qemu-smoke-hyperlaunch-arm32-gcc-debug:
>    extends: .qemu-arm32
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm32-test-needs
>      - debian-unstable-gcc-arm32-debug
>  
> -qemu-smoke-dom0less-arm32-gcc-staticmem:
> +qemu-smoke-hyperlaunch-arm32-gcc-staticmem:
>    extends: .qemu-arm32
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh static-mem 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh static-mem 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm32-test-needs
>      - debian-unstable-gcc-arm32-staticmem
>  
> -qemu-smoke-dom0less-arm32-gcc-debug-staticmem:
> +qemu-smoke-hyperlaunch-arm32-gcc-debug-staticmem:
>    extends: .qemu-arm32
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh static-mem 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh static-mem 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm32-test-needs
>      - debian-unstable-gcc-arm32-debug-staticmem
>  
> -qemu-smoke-dom0less-arm32-gcc-gzip:
> +qemu-smoke-hyperlaunch-arm32-gcc-gzip:
>    extends: .qemu-arm32
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh gzip 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh gzip 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm32-test-needs
>      - debian-unstable-gcc-arm32
>  
> -qemu-smoke-dom0less-arm32-gcc-debug-gzip:
> +qemu-smoke-hyperlaunch-arm32-gcc-debug-gzip:
>    extends: .qemu-arm32
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh gzip 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh gzip 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm32-test-needs
>      - debian-unstable-gcc-arm32-debug
>  
> -qemu-smoke-dom0less-arm32-gcc-without-dom0:
> +qemu-smoke-hyperlaunch-arm32-gcc-without-dom0:
>    extends: .qemu-arm32
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh without-dom0 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh without-dom0 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm32-test-needs
>      - debian-unstable-gcc-arm32
>  
> -qemu-smoke-dom0less-arm32-gcc-debug-without-dom0:
> +qemu-smoke-hyperlaunch-arm32-gcc-debug-without-dom0:
>    extends: .qemu-arm32
>    script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh without-dom0 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh without-dom0 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm32-test-needs
>      - debian-unstable-gcc-arm32-debug
> diff --git a/automation/scripts/qemu-smoke-dom0less-arm32.sh b/automation/scripts/qemu-smoke-hyperlaunch-arm32.sh
> similarity index 100%
> rename from automation/scripts/qemu-smoke-dom0less-arm32.sh
> rename to automation/scripts/qemu-smoke-hyperlaunch-arm32.sh
> diff --git a/automation/scripts/qemu-smoke-dom0less-arm64.sh b/automation/scripts/qemu-smoke-hyperlaunch-arm64.sh
> similarity index 99%
> rename from automation/scripts/qemu-smoke-dom0less-arm64.sh
> rename to automation/scripts/qemu-smoke-hyperlaunch-arm64.sh
> index 75f575424a4e..db22cfaa1fd6 100755
> --- a/automation/scripts/qemu-smoke-dom0less-arm64.sh
> +++ b/automation/scripts/qemu-smoke-hyperlaunch-arm64.sh
> @@ -113,7 +113,7 @@ echo "#!/bin/bash
>  export LD_LIBRARY_PATH=/usr/local/lib
>  bash /etc/init.d/xencommons start
>  
> -/usr/local/lib/xen/bin/init-dom0less
> +/usr/local/lib/xen/bin/init-hyperlaunch-guests
>  
>  brctl addbr xenbr0
>  brctl addif xenbr0 eth0
> diff --git a/automation/scripts/qemu-xtf-dom0less-arm64.sh b/automation/scripts/qemu-xtf-hyperlaunch-arm64.sh
> similarity index 100%
> rename from automation/scripts/qemu-xtf-dom0less-arm64.sh
> rename to automation/scripts/qemu-xtf-hyperlaunch-arm64.sh
> diff --git a/automation/scripts/xilinx-smoke-dom0less-arm64.sh b/automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh
> similarity index 98%
> rename from automation/scripts/xilinx-smoke-dom0less-arm64.sh
> rename to automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh
> index 075305241c8d..35b60720fe08 100755
> --- a/automation/scripts/xilinx-smoke-dom0less-arm64.sh
> +++ b/automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh
> @@ -73,7 +73,7 @@ echo "#!/bin/bash
>  export LD_LIBRARY_PATH=/usr/local/lib
>  bash /etc/init.d/xencommons start
>  
> -/usr/local/lib/xen/bin/init-dom0less
> +/usr/local/lib/xen/bin/init-hyperlaunch-guests
>  
>  ${dom0_check}
>  " > etc/local.d/xen.start
> diff --git a/docs/INDEX b/docs/INDEX
> index e673edd75c31..ed3d2e6198ec 100644
> --- a/docs/INDEX
> +++ b/docs/INDEX
> @@ -25,4 +25,4 @@ misc/arm/early-printk		Enabling early printk on ARM
>  misc/arm/passthrough		Passthrough a device described in the Device Tree to a guest
>  misc/arm/device-tree/booting	Device tree bindings to boot Xen
>  misc/arm/device-tree/passthrough	Device tree binding to passthrough a device
> -features/dom0less.markdown	Boot multiple domains from Xen in parallel
> +features/hyperlaunch.markdown	Boot multiple domains from Xen in parallel
> diff --git a/docs/features/dom0less.pandoc b/docs/features/hyperlaunch.pandoc
> similarity index 84%
> rename from docs/features/dom0less.pandoc
> rename to docs/features/hyperlaunch.pandoc
> index 725afa055838..a62d534696e3 100644
> --- a/docs/features/dom0less.pandoc
> +++ b/docs/features/hyperlaunch.pandoc
> @@ -1,7 +1,7 @@
> -Dom0less
> -========
> +Hyperlaunch
> +===========
>  
> -"Dom0less" is a set of Xen features that enable the deployment of a Xen
> +"Hyperlaunch" is a set of Xen features that enable the deployment of a Xen
>  system without an control domain (often referred to as "dom0"). Each
>  feature can be used independently from the others, unless otherwise
>  stated.
> @@ -93,26 +93,26 @@ See docs/misc/arm/device-tree/booting.txt for more information.
>  PV Drivers
>  ----------
>  
> -It is possible to use PV drivers with dom0less guests with some
> +It is possible to use PV drivers with hyperlaunch started guests with some
>  restrictions:
>  
> -- dom0less domUs that want to use PV drivers support should have the
> +- hyperlaunch started domUs that want to use PV drivers support should have the
>    "xen,enhanced" property set under their device tree nodes (see
>    docs/misc/arm/device-tree/booting.txt)
>  - a dom0 must be present (or another domain with enough privileges to
>    run the toolstack)
> -- after dom0 is booted, the utility "init-dom0less" must be run
> -- do not run "init-dom0less" while creating other guests with xl
> +- after dom0 is booted, the utility "init-hyperlaunch-guests" must be run
> +- do not run "init-hyperlaunch-guests" while creating other guests with xl
>  
> -After the execution of init-dom0less, it is possible to use "xl" to
> -hotplug PV drivers to dom0less guests. E.g. xl network-attach domU.
> +After the execution of init-hyperlaunch-guests, it is possible to use "xl" to
> +hotplug PV drivers to hyperlaunch started guests. E.g. xl network-attach domU.
>  
>  The implementation works as follows:
> -- Xen allocates the xenstore event channel for each dom0less domU that
> -  has the "xen,enhanced" property, and sets HVM_PARAM_STORE_EVTCHN
> +- Xen allocates the xenstore event channel for each hyperlaunch started domU
> +  that has the "xen,enhanced" property, and sets HVM_PARAM_STORE_EVTCHN
>  - Xen does *not* allocate the xenstore page and sets HVM_PARAM_STORE_PFN
>    to ~0ULL (invalid)
> -- Dom0less domU kernels check that HVM_PARAM_STORE_PFN is set to invalid
> +- Hyperlaunch started domU kernels check that HVM_PARAM_STORE_PFN is set to invalid
>      - Old kernels will continue without xenstore support (Note: some old
>        buggy kernels might crash because they don't check the validity of
>        HVM_PARAM_STORE_PFN before using it! Disable "xen,enhanced" in
> @@ -120,7 +120,7 @@ The implementation works as follows:
>      - New kernels will wait for a notification on the xenstore event
>        channel (HVM_PARAM_STORE_EVTCHN) before continuing with the
>        initialization
> -- Once dom0 is booted, init-dom0less is executed:
> +- Once dom0 is booted, init-hyperlaunch-guests is executed:
>      - it allocates the xenstore shared page and sets HVM_PARAM_STORE_PFN
>      - it calls xs_introduce_domain
>  - Xenstored notices the new domain, initializes interfaces as usual, and
> @@ -159,12 +159,13 @@ Notes
>  -----
>  
>  - 'xl console' command will not attach to the domain's console in case
> -  of dom0less. DomU are domains created by Xen (similar to Dom0) and
> -  therefore they are all managed by Xen and some of the commands may not work.
> +  of hyperlaunch started guests. DomU are domains created by Xen (similar to
> +  Dom0) and therefore they are all managed by Xen and some of the commands may
> +  not work.
>  
>    A user is allowed to configure the key sequence to switch input.
>    Pressing the Xen "conswitch" (Ctrl-A by default) three times
> -  switches input in case of dom0less mode.
> +  switches input in case of hyperlaunch mode.
>  
>  - Domains created by Xen will have no name at boot. Domain-0 has a name
>    thanks to the helper xen-init-dom0 called at boot by the initscript.
> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> index bbd955e9c2f6..10ec1910a75a 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -572,8 +572,8 @@ Static Shared Memory
>  ====================
>  
>  The static shared memory device tree nodes allow users to statically set up
> -shared memory on dom0less system, enabling domains to do shm-based
> -communication.
> +shared memory on Hyperlaunch started guests system, enabling domains to do
> +shm-based communication.
>  
>  - compatible
>  
> diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
> index 11c1ac334600..d15cb87b49d1 100644
> --- a/docs/misc/efi.pandoc
> +++ b/docs/misc/efi.pandoc
> @@ -194,12 +194,12 @@ chosen {
>  	};
>  }
>  
> -## UEFI boot and dom0less on ARM
> +## UEFI boot and Hyperlaunch on ARM
>  
> -Dom0less feature is supported by ARM and it is possible to use it when Xen is
> +Hyperlaunch feature is supported by ARM and it is possible to use it when Xen is
>  started as an EFI application.
>  The way to specify the domU domains is by Device Tree as specified in the
> -[dom0less](dom0less.html) documentation page under the "Device Tree
> +[Hyperlaunch](hyperlaunch.html) documentation page under the "Device Tree
>  configuration" section, but instead of declaring the reg property in the boot
>  module, the user must specify the "xen,uefi-binary" property containing the name
>  of the binary file that has to be loaded in memory.
> @@ -236,7 +236,7 @@ domU1 {
>  These are the different ways to boot a Xen system from UEFI:
>  
>   - Boot Xen and Dom0 (minimum required)
> - - Boot Xen and DomU(s) (true dom0less, only on ARM)
> + - Boot Xen and DomU(s) (only on ARM)
>   - Boot Xen, Dom0 and DomU(s) (only on ARM)
>  
>  ### Boot Xen and Dom0
> @@ -247,7 +247,7 @@ example above.
>  ### Boot Xen and DomU(s)
>  
>  This configuration needs the domU domain(s) specified in the /chosen node,
> -examples of how to do that are provided by the documentation about dom0less
> +examples of how to do that are provided by the documentation about Hyperlaunch
>  and the example above shows how to use the "xen,uefi-binary" property to use the
>  UEFI stub for module loading.
>  When adding DomU modules to device tree, also add the property
> @@ -258,7 +258,7 @@ can specify the Xen boot arguments in the configuration file with the "options="
>  keyword or in the device tree with the "xen,xen-bootargs" property, but be
>  aware that the Xen configuration file value has a precedence over the DT value.
>  
> -Example 1 of how to boot a true dom0less configuration:
> +Example 1 of how to boot an Hyperlaunch configuration with only domU(s):
>  
>  Xen configuration file: skipped.
>  
> @@ -301,7 +301,7 @@ chosen {
>  };
>  ```
>  
> -Example 2 of how to boot a true dom0less configuration:
> +Example 2 of how to boot an Hyperlaunch configuration with only domU(s):
>  
>  Xen configuration file:
>  
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 4060ebdc5d76..35d7c9821963 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1156,7 +1156,7 @@ to use the default.
>  > Default : `true`
>  
>  Flag to enable or disable support for extended regions for Dom0 and
> -Dom0less DomUs.
> +Hyperlaunch started DomUs.
>  
>  Extended regions are ranges of unused address space exposed to the guest
>  as "safe to use" for special memory mappings. Disable if your board
> diff --git a/docs/misc/xenstore-ring.txt b/docs/misc/xenstore-ring.txt
> index dbc7335e24b8..f84dedd8016e 100644
> --- a/docs/misc/xenstore-ring.txt
> +++ b/docs/misc/xenstore-ring.txt
> @@ -115,9 +115,9 @@ and reconnect is in progress") and signalling the event channel.
>  The guest must now ignore all fields except the Connection state and
>  wait for it to be set to 0 ("Ring is connected").
>  
> -In certain circumstances (e.g. dom0less guests with PV drivers support)
> -it is possible for the guest to find the Connection state already set to
> -1 by someone else during xenstore initialization. In that case, like in
> +In certain circumstances (e.g. Hyperlaunch started guests with PV drivers
> +support) it is possible for the guest to find the Connection state already set
> +to 1 by someone else during xenstore initialization. In that case, like in
>  the previous case, the guest must ignore all fields except the
>  Connection state and wait for it to be set to 0 before proceeding.
>  
> diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
> index 09590eb5b6f0..332ab47da318 100644
> --- a/tools/helpers/Makefile
> +++ b/tools/helpers/Makefile
> @@ -11,7 +11,7 @@ ifeq ($(CONFIG_X86),y)
>  TARGETS += init-xenstore-domain
>  endif
>  ifeq ($(CONFIG_ARM),y)
> -TARGETS += init-dom0less
> +TARGETS += init-hyperlaunch-guests
>  endif
>  endif
>  
> @@ -31,13 +31,13 @@ $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenlight)
>  $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h
>  init-xenstore-domain: LDLIBS += $(call xenlibs-ldlibs,toollog store ctrl guest light)
>  
> -INIT_DOM0LESS_OBJS = init-dom0less.o init-dom-json.o
> -$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
> -$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenstore)
> -$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenlight)
> -$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
> -$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenevtchn)
> -init-dom0less: LDLIBS += $(call xenlibs-ldlibs,ctrl evtchn toollog store light guest foreignmemory)
> +INIT_HYPERLAUNCH_OBJS = init-hyperlaunch-guests.o init-dom-json.o
> +$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
> +$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxenstore)
> +$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxenlight)
> +$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
> +$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxenevtchn)
> +init-hyperlaunch-guests: LDLIBS += $(call xenlibs-ldlibs,ctrl evtchn toollog store light guest foreignmemory)
>  
>  .PHONY: all
>  all: $(TARGETS)
> @@ -48,8 +48,8 @@ xen-init-dom0: $(XEN_INIT_DOM0_OBJS)
>  init-xenstore-domain: $(INIT_XENSTORE_DOMAIN_OBJS)
>  	$(CC) $(LDFLAGS) -o $@ $(INIT_XENSTORE_DOMAIN_OBJS) $(LDLIBS) $(APPEND_LDFLAGS)
>  
> -init-dom0less: $(INIT_DOM0LESS_OBJS)
> -	$(CC) $(LDFLAGS) -o $@ $(INIT_DOM0LESS_OBJS) $(LDLIBS) $(APPEND_LDFLAGS)
> +init-hyperlaunch-guests: $(INIT_HYPERLAUNCH_OBJS)
> +	$(CC) $(LDFLAGS) -o $@ $(INIT_HYPERLAUNCH_OBJS) $(LDLIBS) $(APPEND_LDFLAGS)
>  
>  .PHONY: install
>  install: all
> diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-hyperlaunch-guests.c
> similarity index 98%
> rename from tools/helpers/init-dom0less.c
> rename to tools/helpers/init-hyperlaunch-guests.c
> index fee93459c4b9..c786a5fd37b2 100644
> --- a/tools/helpers/init-dom0less.c
> +++ b/tools/helpers/init-hyperlaunch-guests.c
> @@ -129,7 +129,7 @@ static int create_xenstore(struct xs_handle *xsh,
>      rc = snprintf(id_str, STR_MAX_LENGTH, "%u", domid);
>      if (rc < 0 || rc >= STR_MAX_LENGTH)
>          return rc;
> -    rc = snprintf(dom_name_str, STR_MAX_LENGTH, "dom0less-%u", domid);
> +    rc = snprintf(dom_name_str, STR_MAX_LENGTH, "hyperlaunch-%u", domid);
>      if (rc < 0 || rc >= STR_MAX_LENGTH)
>          return rc;
>      rc = snprintf(uuid_str, STR_MAX_LENGTH, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
> @@ -232,7 +232,7 @@ static int init_domain(struct xs_handle *xsh,
>      int rc;
>      struct xenstore_domain_interface *intf;
>  
> -    printf("Init dom0less domain: %u\n", info->domid);
> +    printf("Init hyperlaunch domain: %u\n", info->domid);
>  
>      rc = xc_hvm_param_get(xch, info->domid, HVM_PARAM_STORE_EVTCHN,
>                            &xenstore_evtchn);
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 61e581b8c2b0..c5cb8f28011a 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -179,10 +179,10 @@ config TEE
>  source "arch/arm/tee/Kconfig"
>  
>  config STATIC_SHM
> -	bool "Statically shared memory on a dom0less system" if UNSUPPORTED
> +	bool "Statically shared memory on an Hyperlaunch system" if UNSUPPORTED
>  	depends on STATIC_MEMORY
>  	help
> -	  This option enables statically shared memory on a dom0less system.
> +	  This option enables statically shared memory on an Hyperlaunch system.
>  
>  endmenu
>  
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d0d6be922db1..897e1f2de39e 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -42,7 +42,7 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>  
>  /*
>   * If true, the extended regions support is enabled for dom0 and
> - * dom0less domUs.
> + * Hyperlaunch started domUs.
>   */
>  static bool __initdata opt_ext_regions = true;
>  boolean_param("ext_regions", opt_ext_regions);
> @@ -3347,7 +3347,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
>              goto err;
>      }
>  
> -    if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS )
> +    if ( kinfo->hyperlaunch_feature & HYPERLAUNCH_ENHANCED_NO_XS )
>      {
>          ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
>          if ( ret )
> @@ -3810,7 +3810,7 @@ static int __init construct_domU(struct domain *d,
>                                   const struct dt_device_node *node)
>  {
>      struct kernel_info kinfo = {};
> -    const char *dom0less_enhanced;
> +    const char *hyperlaunch_enhanced;
>      int rc;
>      u64 mem;
>      u32 p2m_mem_mb;
> @@ -3841,18 +3841,18 @@ static int __init construct_domU(struct domain *d,
>  
>      kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
>  
> -    rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
> +    rc = dt_property_read_string(node, "xen,enhanced", &hyperlaunch_enhanced);
>      if ( rc == -EILSEQ ||
>           rc == -ENODATA ||
> -         (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) )
> +         (rc == 0 && !strcmp(hyperlaunch_enhanced, "enabled")) )
>      {
>          if ( hardware_domain )
> -            kinfo.dom0less_feature = DOM0LESS_ENHANCED;
> +            kinfo.hyperlaunch_feature = HYPERLAUNCH_ENHANCED;
>          else
>              panic("At the moment, Xenstore support requires dom0 to be present\n");
>      }
> -    else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") )
> -        kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS;
> +    else if ( rc == 0 && !strcmp(hyperlaunch_enhanced, "no-xenstore") )
> +        kinfo.hyperlaunch_feature = HYPERLAUNCH_ENHANCED_NO_XS;
>  
>      if ( vcpu_create(d, 0) == NULL )
>          return -ENOMEM;
> @@ -3902,7 +3902,7 @@ static int __init construct_domU(struct domain *d,
>      if ( rc < 0 )
>          return rc;
>  
> -    if ( kinfo.dom0less_feature & DOM0LESS_XENSTORE )
> +    if ( kinfo.hyperlaunch_feature & HYPERLAUNCH_XENSTORE )
>      {
>          ASSERT(hardware_domain);
>          rc = alloc_xenstore_evtchn(d);
> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> index bb64925d708c..cccf90817279 100644
> --- a/xen/arch/arm/efi/efi-boot.h
> +++ b/xen/arch/arm/efi/efi-boot.h
> @@ -807,9 +807,9 @@ static int __init handle_module_node(const EFI_LOADED_IMAGE *loaded_image,
>   * in the DT.
>   * Returns number of multiboot,module found or negative number on error.
>   */
> -static int __init handle_dom0less_domain_node(const EFI_LOADED_IMAGE *loaded_image,
> -                                              EFI_FILE_HANDLE *dir_handle,
> -                                              int domain_node)
> +static int __init
> +handle_hyperlaunch_domain_node(const EFI_LOADED_IMAGE *loaded_image,
> +                               EFI_FILE_HANDLE *dir_handle, int domain_node)
>  {
>      int module_node, addr_cells, size_cells, len;
>      const struct fdt_property *prop;
> @@ -879,7 +879,8 @@ static int __init efi_check_dt_boot(const EFI_LOADED_IMAGE *loaded_image)
>          if ( !fdt_node_check_compatible(fdt, node, "xen,domain") )
>          {
>              /* Found a node with compatible xen,domain; handle this node. */
> -            ret = handle_dom0less_domain_node(loaded_image, &dir_handle, node);
> +            ret = handle_hyperlaunch_domain_node(loaded_image, &dir_handle,
> +                                                 node);
>              if ( ret < 0 )
>                  return ERROR_DT_MODULE_DOMU;
>          }
> diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
> index 4617cdc83bac..042e250e172a 100644
> --- a/xen/arch/arm/include/asm/kernel.h
> +++ b/xen/arch/arm/include/asm/kernel.h
> @@ -10,23 +10,23 @@
>  #include <asm/setup.h>
>  
>  /*
> - * List of possible features for dom0less domUs
> + * List of possible features for Hyperlaunch started domUs
>   *
> - * DOM0LESS_ENHANCED_NO_XS: Notify the OS it is running on top of Xen. All the
> - *                          default features (excluding Xenstore) will be
> - *                          available. Note that an OS *must* not rely on the
> - *                          availability of Xen features if this is not set.
> - * DOM0LESS_XENSTORE:       Xenstore will be enabled for the VM. This feature
> - *                          can't be enabled without the
> - *                          DOM0LESS_ENHANCED_NO_XS.
> - * DOM0LESS_ENHANCED:       Notify the OS it is running on top of Xen. All the
> - *                          default features (including Xenstore) will be
> - *                          available. Note that an OS *must* not rely on the
> - *                          availability of Xen features if this is not set.
> + * HYPERLAUNCH_ENHANCED_NO_XS: Notify the OS it is running on top of Xen. All
> + *                             the default features (excluding Xenstore) will be
> + *                             available. Note that an OS *must* not rely on the
> + *                             availability of Xen features if this is not set.
> + * HYPERLAUNCH_XENSTORE:       Xenstore will be enabled for the VM. This feature
> + *                             can't be enabled without the
> + *                             HYPERLAUNCH_ENHANCED_NO_XS.
> + * HYPERLAUNCH_ENHANCED:       Notify the OS it is running on top of Xen. All
> + *                             the default features (including Xenstore) will be
> + *                             available. Note that an OS *must* not rely on the
> + *                             availability of Xen features if this is not set.
>   */
> -#define DOM0LESS_ENHANCED_NO_XS  BIT(0, U)
> -#define DOM0LESS_XENSTORE        BIT(1, U)
> -#define DOM0LESS_ENHANCED        (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE)
> +#define HYPERLAUNCH_ENHANCED_NO_XS  BIT(0, U)
> +#define HYPERLAUNCH_XENSTORE        BIT(1, U)
> +#define HYPERLAUNCH_ENHANCED        (HYPERLAUNCH_ENHANCED_NO_XS | HYPERLAUNCH_XENSTORE)
>  
>  struct kernel_info {
>  #ifdef CONFIG_ARM_64
> @@ -57,7 +57,7 @@ struct kernel_info {
>      bool vpl011;
>  
>      /* Enable/Disable PV drivers interfaces */
> -    uint16_t dom0less_feature;
> +    uint16_t hyperlaunch_feature;
>  
>      /* GIC phandle */
>      uint32_t phandle_gic;
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index bbf72b69aae6..955c6b9e2e9e 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -1041,7 +1041,7 @@ static void __init setup_mm(void)
>  }
>  #endif
>  
> -static bool __init is_dom0less_mode(void)
> +static bool __init is_hyperlaunch_mode(void)
>  {
>      struct bootmodules *mods = &bootinfo.modules;
>      struct bootmodule *mod;
> @@ -1068,7 +1068,7 @@ static bool __init is_dom0less_mode(void)
>  
>      /*
>       * If there is no dom0 kernel but at least one domU, then we are in
> -     * dom0less mode
> +     * Hyperlaunch mode
>       */
>      return ( !dom0found && domUfound );
>  }
> @@ -1242,10 +1242,10 @@ void __init start_xen(unsigned long boot_phys_offset,
>      enable_cpu_features();
>  
>      /* Create initial domain 0. */
> -    if ( !is_dom0less_mode() )
> +    if ( !is_hyperlaunch_mode() )
>          create_dom0();
>      else
> -        printk(XENLOG_INFO "Xen dom0less mode detected\n");
> +        printk(XENLOG_INFO "Xen Hyperlaunch mode detected\n");
>  
>      if ( acpi_disabled )
>      {
> -- 
> 2.34.1
>
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Elliott Mitchell 10 months ago 
On Fri, Jun 30, 2023 at 10:12:10AM +0100, Luca Fancellu wrote:
> This is an RFC to get the feeling of the community about the name
> change, for now it's everything in one patch just to see how it
> will look like, if there is interest on proceeding into it, I can
> split in more commit.

I seem to recall something else using the term "hyperlaunch".  I'm though
unable to find the reference.

"dom0less" might be a poor name choice, but my initial feeling is to
prefer it to "hyperlaunch".

Perhaps "dom0--", "dom0decrement" or "dom0alternative" since it is
providing an alternative approach to services previously offered by
Domain 0?


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Julien Grall 10 months ago 
(+ Christopher and Daniel)

On 30/06/2023 10:12, Luca Fancellu wrote:
> The "dom0less" feature was intended to be the feature where a domU
> domain could be launched without the control domain (Dom0)
> intervention, however the name seems to suggest that Dom0 cannot
> be part of the configuration, while instead it's a possible use case.
> 
> To avoid that, rename the "dom0less" configuration with the name
> "hyperlaunch", that is less misleading.
> 
> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
> ---
> This is an RFC to get the feeling of the community about the name
> change, for now it's everything in one patch just to see how it
> will look like, if there is interest on proceeding into it, I can
> split in more commit.
> Please note that I've left intentionally "dom0less" into the
> docs/design/ and CHANGELOG.md
> ---
> ---
>   .gitignore                                    |  2 +-
>   CHANGELOG.md                                  |  2 +
>   SUPPORT.md                                    |  8 +-
>   automation/gitlab-ci/test.yaml                | 88 +++++++++----------
>   ...m32.sh => qemu-smoke-hyperlaunch-arm32.sh} |  0
>   ...m64.sh => qemu-smoke-hyperlaunch-arm64.sh} |  2 +-
>   ...arm64.sh => qemu-xtf-hyperlaunch-arm64.sh} |  0
>   ...4.sh => xilinx-smoke-hyperlaunch-arm64.sh} |  2 +-
>   docs/INDEX                                    |  2 +-
>   .../{dom0less.pandoc => hyperlaunch.pandoc}   | 33 +++----
>   docs/misc/arm/device-tree/booting.txt         |  4 +-
>   docs/misc/efi.pandoc                          | 14 +--
>   docs/misc/xen-command-line.pandoc             |  2 +-
>   docs/misc/xenstore-ring.txt                   |  6 +-
>   tools/helpers/Makefile                        | 20 ++---
>   ...t-dom0less.c => init-hyperlaunch-guests.c} |  4 +-
>   xen/arch/arm/Kconfig                          |  4 +-
>   xen/arch/arm/domain_build.c                   | 18 ++--
>   xen/arch/arm/efi/efi-boot.h                   |  9 +-
>   xen/arch/arm/include/asm/kernel.h             | 32 +++----
>   xen/arch/arm/setup.c                          |  8 +-
>   21 files changed, 132 insertions(+), 128 deletions(-)
>   rename automation/scripts/{qemu-smoke-dom0less-arm32.sh => qemu-smoke-hyperlaunch-arm32.sh} (100%)
>   rename automation/scripts/{qemu-smoke-dom0less-arm64.sh => qemu-smoke-hyperlaunch-arm64.sh} (99%)
>   rename automation/scripts/{qemu-xtf-dom0less-arm64.sh => qemu-xtf-hyperlaunch-arm64.sh} (100%)
>   rename automation/scripts/{xilinx-smoke-dom0less-arm64.sh => xilinx-smoke-hyperlaunch-arm64.sh} (98%)
>   rename docs/features/{dom0less.pandoc => hyperlaunch.pandoc} (84%)
>   rename tools/helpers/{init-dom0less.c => init-hyperlaunch-guests.c} (98%)
> 
> diff --git a/.gitignore b/.gitignore
> index c1b73b096893..c9d569247079 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -167,7 +167,7 @@ tools/flask/utils/flask-loadpolicy
>   tools/flask/utils/flask-setenforce
>   tools/flask/utils/flask-set-bool
>   tools/flask/utils/flask-label-pci
> -tools/helpers/init-dom0less
> +tools/helpers/init-hyperlaunch-guests
>   tools/helpers/init-xenstore-domain
>   tools/helpers/xen-init-dom0
>   tools/hotplug/common/hotplugpath.sh
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 7d7e0590f8c6..cf01e004b017 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -13,6 +13,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>      known user doesn't use it properly, leading to in-guest breakage.
>    - The "dom0" option is now supported on Arm and "sve=" sub-option can be used
>      to enable dom0 guest to use SVE/SVE2 instructions.
> + - The "dom0less" feature, currently supported only on arm, is renamed to
> +   "hyperlaunch".
>   
>   ### Added
>    - On x86, support for features new in Intel Sapphire Rapids CPUs:
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 35a6249e03b2..fe500652828c 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -342,7 +342,7 @@ Allow sharing of identical pages between guests
>   
>   ### Static Memory Sharing
>   
> -Allow to statically set up shared memory on dom0less system,
> +Allow to statically set up shared memory on hyperlaunch system,
>   enabling domains to do shm-based communication
>   
>       Status, ARM: Tech Preview
> @@ -945,20 +945,20 @@ OVMF firmware implements the UEFI boot protocol.
>   
>       Status, qemu-xen: Supported
>   
> -## Dom0less
> +## Hyperlaunch
>   
>   Guest creation from the hypervisor at boot without Dom0 intervention.
>   
>       Status, ARM: Supported
>   
> -Memory of dom0less DomUs is not scrubbed at boot when bootscrub=on or
> +Memory of hyperlaunch DomUs is not scrubbed at boot when bootscrub=on or
>   bootscrub=off are passed as Xen command line parameters. (Memory should
>   be scrubbed with bootscrub=idle.) No XSAs will be issues due to
>   unscrubbed memory.
>   
>   ## Static Event Channel
>   
> -Allow to setup the static event channel on dom0less system, enabling domains
> +Allow to setup the static event channel on hyperlaunch system, enabling domains
>   to send/receive notifications.
>   
>       Status, ARM: Tech Preview
> diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
> index d5cb238b0ad8..d309c784b643 100644
> --- a/automation/gitlab-ci/test.yaml
> +++ b/automation/gitlab-ci/test.yaml
> @@ -136,18 +136,18 @@ build-each-commit-gcc:
>     tags:
>       - x86_64
>   
> -xilinx-smoke-dom0less-arm64-gcc:
> +xilinx-smoke-hyperlaunch-arm64-gcc:
>     extends: .xilinx-arm64
>     script:
> -    - ./automation/scripts/xilinx-smoke-dom0less-arm64.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm64-test-needs
>       - alpine-3.12-gcc-arm64
>   
> -xilinx-smoke-dom0less-arm64-gcc-gem-passthrough:
> +xilinx-smoke-hyperlaunch-arm64-gcc-gem-passthrough:
>     extends: .xilinx-arm64
>     script:
> -    - ./automation/scripts/xilinx-smoke-dom0less-arm64.sh gem-passthrough 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh gem-passthrough 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm64-test-needs
>       - alpine-3.12-gcc-arm64
> @@ -234,98 +234,98 @@ qemu-smoke-dom0-arm64-gcc-debug:
>       - *arm64-test-needs
>       - alpine-3.12-gcc-debug-arm64
>   
> -qemu-smoke-dom0less-arm64-gcc:
> +qemu-smoke-hyperlaunch-arm64-gcc:
>     extends: .qemu-arm64
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm64-test-needs
>       - alpine-3.12-gcc-arm64
>   
> -qemu-smoke-dom0less-arm64-gcc-debug:
> +qemu-smoke-hyperlaunch-arm64-gcc-debug:
>     extends: .qemu-arm64
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm64-test-needs
>       - alpine-3.12-gcc-debug-arm64
>   
> -qemu-smoke-dom0less-arm64-gcc-staticmem:
> +qemu-smoke-hyperlaunch-arm64-gcc-staticmem:
>     extends: .qemu-arm64
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-mem 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-mem 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm64-test-needs
>       - alpine-3.12-gcc-arm64-staticmem
>   
> -qemu-smoke-dom0less-arm64-gcc-debug-staticmem:
> +qemu-smoke-hyperlaunch-arm64-gcc-debug-staticmem:
>     extends: .qemu-arm64
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-mem 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-mem 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm64-test-needs
>       - alpine-3.12-gcc-debug-arm64-staticmem
>   
> -qemu-smoke-dom0less-arm64-gcc-staticheap:
> +qemu-smoke-hyperlaunch-arm64-gcc-staticheap:
>    extends: .qemu-arm64
>    script:
> -   - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-heap 2>&1 | tee ${LOGFILE}
> +   - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-heap 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm64-test-needs
>      - alpine-3.12-gcc-arm64
>   
> -qemu-smoke-dom0less-arm64-gcc-debug-staticheap:
> +qemu-smoke-hyperlaunch-arm64-gcc-debug-staticheap:
>    extends: .qemu-arm64
>    script:
> -   - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-heap 2>&1 | tee ${LOGFILE}
> +   - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-heap 2>&1 | tee ${LOGFILE}
>    needs:
>      - *arm64-test-needs
>      - alpine-3.12-gcc-debug-arm64
>   
> -qemu-smoke-dom0less-arm64-gcc-static-shared-mem:
> +qemu-smoke-hyperlaunch-arm64-gcc-static-shared-mem:
>     extends: .qemu-arm64
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-shared-mem 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-shared-mem 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm64-test-needs
>       - alpine-3.12-gcc-arm64-static-shared-mem
>   
> -qemu-smoke-dom0less-arm64-gcc-debug-static-shared-mem:
> +qemu-smoke-hyperlaunch-arm64-gcc-debug-static-shared-mem:
>     extends: .qemu-arm64
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh static-shared-mem 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh static-shared-mem 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm64-test-needs
>       - alpine-3.12-gcc-debug-arm64-static-shared-mem
>   
> -qemu-smoke-dom0less-arm64-gcc-boot-cpupools:
> +qemu-smoke-hyperlaunch-arm64-gcc-boot-cpupools:
>     extends: .qemu-arm64
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh boot-cpupools 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh boot-cpupools 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm64-test-needs
>       - alpine-3.12-gcc-arm64-boot-cpupools
>   
> -qemu-smoke-dom0less-arm64-gcc-debug-boot-cpupools:
> +qemu-smoke-hyperlaunch-arm64-gcc-debug-boot-cpupools:
>     extends: .qemu-arm64
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm64.sh boot-cpupools 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm64.sh boot-cpupools 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm64-test-needs
>       - alpine-3.12-gcc-debug-arm64-boot-cpupools
>   
> -qemu-xtf-dom0less-arm64-gcc-hyp-xen-version:
> +qemu-xtf-hyperlaunch-arm64-gcc-hyp-xen-version:
>     extends: .qemu-arm64
>     script:
> -    - ./automation/scripts/qemu-xtf-dom0less-arm64.sh hyp-xen-version 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-xtf-hyperlaunch-arm64.sh hyp-xen-version 2>&1 | tee ${LOGFILE}
>     needs:
>       - alpine-3.12-gcc-arm64
>       - qemu-system-aarch64-6.0.0-arm64-export
>   
> -qemu-xtf-dom0less-arm64-gcc-debug-hyp-xen-version:
> +qemu-xtf-hyperlaunch-arm64-gcc-debug-hyp-xen-version:
>     extends: .qemu-arm64
>     script:
> -    - ./automation/scripts/qemu-xtf-dom0less-arm64.sh hyp-xen-version 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-xtf-hyperlaunch-arm64.sh hyp-xen-version 2>&1 | tee ${LOGFILE}
>     needs:
>       - alpine-3.12-gcc-debug-arm64
>       - qemu-system-aarch64-6.0.0-arm64-export
> @@ -338,66 +338,66 @@ qemu-smoke-dom0-arm32-gcc:
>       - *arm32-test-needs
>       - yocto-qemuarm
>   
> -qemu-smoke-dom0less-arm32-gcc:
> +qemu-smoke-hyperlaunch-arm32-gcc:
>     extends: .qemu-arm32
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm32-test-needs
>       - debian-unstable-gcc-arm32
>   
> -qemu-smoke-dom0less-arm32-gcc-debug:
> +qemu-smoke-hyperlaunch-arm32-gcc-debug:
>     extends: .qemu-arm32
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm32-test-needs
>       - debian-unstable-gcc-arm32-debug
>   
> -qemu-smoke-dom0less-arm32-gcc-staticmem:
> +qemu-smoke-hyperlaunch-arm32-gcc-staticmem:
>     extends: .qemu-arm32
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh static-mem 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh static-mem 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm32-test-needs
>       - debian-unstable-gcc-arm32-staticmem
>   
> -qemu-smoke-dom0less-arm32-gcc-debug-staticmem:
> +qemu-smoke-hyperlaunch-arm32-gcc-debug-staticmem:
>     extends: .qemu-arm32
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh static-mem 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh static-mem 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm32-test-needs
>       - debian-unstable-gcc-arm32-debug-staticmem
>   
> -qemu-smoke-dom0less-arm32-gcc-gzip:
> +qemu-smoke-hyperlaunch-arm32-gcc-gzip:
>     extends: .qemu-arm32
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh gzip 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh gzip 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm32-test-needs
>       - debian-unstable-gcc-arm32
>   
> -qemu-smoke-dom0less-arm32-gcc-debug-gzip:
> +qemu-smoke-hyperlaunch-arm32-gcc-debug-gzip:
>     extends: .qemu-arm32
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh gzip 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh gzip 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm32-test-needs
>       - debian-unstable-gcc-arm32-debug
>   
> -qemu-smoke-dom0less-arm32-gcc-without-dom0:
> +qemu-smoke-hyperlaunch-arm32-gcc-without-dom0:
>     extends: .qemu-arm32
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh without-dom0 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh without-dom0 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm32-test-needs
>       - debian-unstable-gcc-arm32
>   
> -qemu-smoke-dom0less-arm32-gcc-debug-without-dom0:
> +qemu-smoke-hyperlaunch-arm32-gcc-debug-without-dom0:
>     extends: .qemu-arm32
>     script:
> -    - ./automation/scripts/qemu-smoke-dom0less-arm32.sh without-dom0 2>&1 | tee ${LOGFILE}
> +    - ./automation/scripts/qemu-smoke-hyperlaunch-arm32.sh without-dom0 2>&1 | tee ${LOGFILE}
>     needs:
>       - *arm32-test-needs
>       - debian-unstable-gcc-arm32-debug
> diff --git a/automation/scripts/qemu-smoke-dom0less-arm32.sh b/automation/scripts/qemu-smoke-hyperlaunch-arm32.sh
> similarity index 100%
> rename from automation/scripts/qemu-smoke-dom0less-arm32.sh
> rename to automation/scripts/qemu-smoke-hyperlaunch-arm32.sh
> diff --git a/automation/scripts/qemu-smoke-dom0less-arm64.sh b/automation/scripts/qemu-smoke-hyperlaunch-arm64.sh
> similarity index 99%
> rename from automation/scripts/qemu-smoke-dom0less-arm64.sh
> rename to automation/scripts/qemu-smoke-hyperlaunch-arm64.sh
> index 75f575424a4e..db22cfaa1fd6 100755
> --- a/automation/scripts/qemu-smoke-dom0less-arm64.sh
> +++ b/automation/scripts/qemu-smoke-hyperlaunch-arm64.sh
> @@ -113,7 +113,7 @@ echo "#!/bin/bash
>   export LD_LIBRARY_PATH=/usr/local/lib
>   bash /etc/init.d/xencommons start
>   
> -/usr/local/lib/xen/bin/init-dom0less
> +/usr/local/lib/xen/bin/init-hyperlaunch-guests
>   
>   brctl addbr xenbr0
>   brctl addif xenbr0 eth0
> diff --git a/automation/scripts/qemu-xtf-dom0less-arm64.sh b/automation/scripts/qemu-xtf-hyperlaunch-arm64.sh
> similarity index 100%
> rename from automation/scripts/qemu-xtf-dom0less-arm64.sh
> rename to automation/scripts/qemu-xtf-hyperlaunch-arm64.sh
> diff --git a/automation/scripts/xilinx-smoke-dom0less-arm64.sh b/automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh
> similarity index 98%
> rename from automation/scripts/xilinx-smoke-dom0less-arm64.sh
> rename to automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh
> index 075305241c8d..35b60720fe08 100755
> --- a/automation/scripts/xilinx-smoke-dom0less-arm64.sh
> +++ b/automation/scripts/xilinx-smoke-hyperlaunch-arm64.sh
> @@ -73,7 +73,7 @@ echo "#!/bin/bash
>   export LD_LIBRARY_PATH=/usr/local/lib
>   bash /etc/init.d/xencommons start
>   
> -/usr/local/lib/xen/bin/init-dom0less
> +/usr/local/lib/xen/bin/init-hyperlaunch-guests
>   
>   ${dom0_check}
>   " > etc/local.d/xen.start
> diff --git a/docs/INDEX b/docs/INDEX
> index e673edd75c31..ed3d2e6198ec 100644
> --- a/docs/INDEX
> +++ b/docs/INDEX
> @@ -25,4 +25,4 @@ misc/arm/early-printk		Enabling early printk on ARM
>   misc/arm/passthrough		Passthrough a device described in the Device Tree to a guest
>   misc/arm/device-tree/booting	Device tree bindings to boot Xen
>   misc/arm/device-tree/passthrough	Device tree binding to passthrough a device
> -features/dom0less.markdown	Boot multiple domains from Xen in parallel
> +features/hyperlaunch.markdown	Boot multiple domains from Xen in parallel
> diff --git a/docs/features/dom0less.pandoc b/docs/features/hyperlaunch.pandoc
> similarity index 84%
> rename from docs/features/dom0less.pandoc
> rename to docs/features/hyperlaunch.pandoc
> index 725afa055838..a62d534696e3 100644
> --- a/docs/features/dom0less.pandoc
> +++ b/docs/features/hyperlaunch.pandoc
> @@ -1,7 +1,7 @@
> -Dom0less
> -========
> +Hyperlaunch
> +===========
>   
> -"Dom0less" is a set of Xen features that enable the deployment of a Xen
> +"Hyperlaunch" is a set of Xen features that enable the deployment of a Xen
>   system without an control domain (often referred to as "dom0"). Each
>   feature can be used independently from the others, unless otherwise
>   stated.
> @@ -93,26 +93,26 @@ See docs/misc/arm/device-tree/booting.txt for more information.
>   PV Drivers
>   ----------
>   
> -It is possible to use PV drivers with dom0less guests with some
> +It is possible to use PV drivers with hyperlaunch started guests with some
>   restrictions:
>   
> -- dom0less domUs that want to use PV drivers support should have the
> +- hyperlaunch started domUs that want to use PV drivers support should have the
>     "xen,enhanced" property set under their device tree nodes (see
>     docs/misc/arm/device-tree/booting.txt)
>   - a dom0 must be present (or another domain with enough privileges to
>     run the toolstack)
> -- after dom0 is booted, the utility "init-dom0less" must be run
> -- do not run "init-dom0less" while creating other guests with xl
> +- after dom0 is booted, the utility "init-hyperlaunch-guests" must be run
> +- do not run "init-hyperlaunch-guests" while creating other guests with xl
>   
> -After the execution of init-dom0less, it is possible to use "xl" to
> -hotplug PV drivers to dom0less guests. E.g. xl network-attach domU.
> +After the execution of init-hyperlaunch-guests, it is possible to use "xl" to
> +hotplug PV drivers to hyperlaunch started guests. E.g. xl network-attach domU.
>   
>   The implementation works as follows:
> -- Xen allocates the xenstore event channel for each dom0less domU that
> -  has the "xen,enhanced" property, and sets HVM_PARAM_STORE_EVTCHN
> +- Xen allocates the xenstore event channel for each hyperlaunch started domU
> +  that has the "xen,enhanced" property, and sets HVM_PARAM_STORE_EVTCHN
>   - Xen does *not* allocate the xenstore page and sets HVM_PARAM_STORE_PFN
>     to ~0ULL (invalid)
> -- Dom0less domU kernels check that HVM_PARAM_STORE_PFN is set to invalid
> +- Hyperlaunch started domU kernels check that HVM_PARAM_STORE_PFN is set to invalid
>       - Old kernels will continue without xenstore support (Note: some old
>         buggy kernels might crash because they don't check the validity of
>         HVM_PARAM_STORE_PFN before using it! Disable "xen,enhanced" in
> @@ -120,7 +120,7 @@ The implementation works as follows:
>       - New kernels will wait for a notification on the xenstore event
>         channel (HVM_PARAM_STORE_EVTCHN) before continuing with the
>         initialization
> -- Once dom0 is booted, init-dom0less is executed:
> +- Once dom0 is booted, init-hyperlaunch-guests is executed:
>       - it allocates the xenstore shared page and sets HVM_PARAM_STORE_PFN
>       - it calls xs_introduce_domain
>   - Xenstored notices the new domain, initializes interfaces as usual, and
> @@ -159,12 +159,13 @@ Notes
>   -----
>   
>   - 'xl console' command will not attach to the domain's console in case
> -  of dom0less. DomU are domains created by Xen (similar to Dom0) and
> -  therefore they are all managed by Xen and some of the commands may not work.
> +  of hyperlaunch started guests. DomU are domains created by Xen (similar to
> +  Dom0) and therefore they are all managed by Xen and some of the commands may
> +  not work.
>   
>     A user is allowed to configure the key sequence to switch input.
>     Pressing the Xen "conswitch" (Ctrl-A by default) three times
> -  switches input in case of dom0less mode.
> +  switches input in case of hyperlaunch mode.
>   
>   - Domains created by Xen will have no name at boot. Domain-0 has a name
>     thanks to the helper xen-init-dom0 called at boot by the initscript.
> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> index bbd955e9c2f6..10ec1910a75a 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -572,8 +572,8 @@ Static Shared Memory
>   ====================
>   
>   The static shared memory device tree nodes allow users to statically set up
> -shared memory on dom0less system, enabling domains to do shm-based
> -communication.
> +shared memory on Hyperlaunch started guests system, enabling domains to do
> +shm-based communication.
>   
>   - compatible
>   
> diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
> index 11c1ac334600..d15cb87b49d1 100644
> --- a/docs/misc/efi.pandoc
> +++ b/docs/misc/efi.pandoc
> @@ -194,12 +194,12 @@ chosen {
>   	};
>   }
>   
> -## UEFI boot and dom0less on ARM
> +## UEFI boot and Hyperlaunch on ARM
>   
> -Dom0less feature is supported by ARM and it is possible to use it when Xen is
> +Hyperlaunch feature is supported by ARM and it is possible to use it when Xen is
>   started as an EFI application.
>   The way to specify the domU domains is by Device Tree as specified in the
> -[dom0less](dom0less.html) documentation page under the "Device Tree
> +[Hyperlaunch](hyperlaunch.html) documentation page under the "Device Tree
>   configuration" section, but instead of declaring the reg property in the boot
>   module, the user must specify the "xen,uefi-binary" property containing the name
>   of the binary file that has to be loaded in memory.
> @@ -236,7 +236,7 @@ domU1 {
>   These are the different ways to boot a Xen system from UEFI:
>   
>    - Boot Xen and Dom0 (minimum required)
> - - Boot Xen and DomU(s) (true dom0less, only on ARM)
> + - Boot Xen and DomU(s) (only on ARM)
>    - Boot Xen, Dom0 and DomU(s) (only on ARM)
>   
>   ### Boot Xen and Dom0
> @@ -247,7 +247,7 @@ example above.
>   ### Boot Xen and DomU(s)
>   
>   This configuration needs the domU domain(s) specified in the /chosen node,
> -examples of how to do that are provided by the documentation about dom0less
> +examples of how to do that are provided by the documentation about Hyperlaunch
>   and the example above shows how to use the "xen,uefi-binary" property to use the
>   UEFI stub for module loading.
>   When adding DomU modules to device tree, also add the property
> @@ -258,7 +258,7 @@ can specify the Xen boot arguments in the configuration file with the "options="
>   keyword or in the device tree with the "xen,xen-bootargs" property, but be
>   aware that the Xen configuration file value has a precedence over the DT value.
>   
> -Example 1 of how to boot a true dom0less configuration:
> +Example 1 of how to boot an Hyperlaunch configuration with only domU(s):
>   
>   Xen configuration file: skipped.
>   
> @@ -301,7 +301,7 @@ chosen {
>   };
>   ```
>   
> -Example 2 of how to boot a true dom0less configuration:
> +Example 2 of how to boot an Hyperlaunch configuration with only domU(s):
>   
>   Xen configuration file:
>   
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 4060ebdc5d76..35d7c9821963 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1156,7 +1156,7 @@ to use the default.
>   > Default : `true`
>   
>   Flag to enable or disable support for extended regions for Dom0 and
> -Dom0less DomUs.
> +Hyperlaunch started DomUs.
>   
>   Extended regions are ranges of unused address space exposed to the guest
>   as "safe to use" for special memory mappings. Disable if your board
> diff --git a/docs/misc/xenstore-ring.txt b/docs/misc/xenstore-ring.txt
> index dbc7335e24b8..f84dedd8016e 100644
> --- a/docs/misc/xenstore-ring.txt
> +++ b/docs/misc/xenstore-ring.txt
> @@ -115,9 +115,9 @@ and reconnect is in progress") and signalling the event channel.
>   The guest must now ignore all fields except the Connection state and
>   wait for it to be set to 0 ("Ring is connected").
>   
> -In certain circumstances (e.g. dom0less guests with PV drivers support)
> -it is possible for the guest to find the Connection state already set to
> -1 by someone else during xenstore initialization. In that case, like in
> +In certain circumstances (e.g. Hyperlaunch started guests with PV drivers
> +support) it is possible for the guest to find the Connection state already set
> +to 1 by someone else during xenstore initialization. In that case, like in
>   the previous case, the guest must ignore all fields except the
>   Connection state and wait for it to be set to 0 before proceeding.
>   
> diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
> index 09590eb5b6f0..332ab47da318 100644
> --- a/tools/helpers/Makefile
> +++ b/tools/helpers/Makefile
> @@ -11,7 +11,7 @@ ifeq ($(CONFIG_X86),y)
>   TARGETS += init-xenstore-domain
>   endif
>   ifeq ($(CONFIG_ARM),y)
> -TARGETS += init-dom0less
> +TARGETS += init-hyperlaunch-guests
>   endif
>   endif
>   
> @@ -31,13 +31,13 @@ $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenlight)
>   $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h
>   init-xenstore-domain: LDLIBS += $(call xenlibs-ldlibs,toollog store ctrl guest light)
>   
> -INIT_DOM0LESS_OBJS = init-dom0less.o init-dom-json.o
> -$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
> -$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenstore)
> -$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenlight)
> -$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
> -$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenevtchn)
> -init-dom0less: LDLIBS += $(call xenlibs-ldlibs,ctrl evtchn toollog store light guest foreignmemory)
> +INIT_HYPERLAUNCH_OBJS = init-hyperlaunch-guests.o init-dom-json.o
> +$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
> +$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxenstore)
> +$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxenlight)
> +$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
> +$(INIT_HYPERLAUNCH_OBJS): CFLAGS += $(CFLAGS_libxenevtchn)
> +init-hyperlaunch-guests: LDLIBS += $(call xenlibs-ldlibs,ctrl evtchn toollog store light guest foreignmemory)
>   
>   .PHONY: all
>   all: $(TARGETS)
> @@ -48,8 +48,8 @@ xen-init-dom0: $(XEN_INIT_DOM0_OBJS)
>   init-xenstore-domain: $(INIT_XENSTORE_DOMAIN_OBJS)
>   	$(CC) $(LDFLAGS) -o $@ $(INIT_XENSTORE_DOMAIN_OBJS) $(LDLIBS) $(APPEND_LDFLAGS)
>   
> -init-dom0less: $(INIT_DOM0LESS_OBJS)
> -	$(CC) $(LDFLAGS) -o $@ $(INIT_DOM0LESS_OBJS) $(LDLIBS) $(APPEND_LDFLAGS)
> +init-hyperlaunch-guests: $(INIT_HYPERLAUNCH_OBJS)
> +	$(CC) $(LDFLAGS) -o $@ $(INIT_HYPERLAUNCH_OBJS) $(LDLIBS) $(APPEND_LDFLAGS)
>   
>   .PHONY: install
>   install: all
> diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-hyperlaunch-guests.c
> similarity index 98%
> rename from tools/helpers/init-dom0less.c
> rename to tools/helpers/init-hyperlaunch-guests.c
> index fee93459c4b9..c786a5fd37b2 100644
> --- a/tools/helpers/init-dom0less.c
> +++ b/tools/helpers/init-hyperlaunch-guests.c
> @@ -129,7 +129,7 @@ static int create_xenstore(struct xs_handle *xsh,
>       rc = snprintf(id_str, STR_MAX_LENGTH, "%u", domid);
>       if (rc < 0 || rc >= STR_MAX_LENGTH)
>           return rc;
> -    rc = snprintf(dom_name_str, STR_MAX_LENGTH, "dom0less-%u", domid);
> +    rc = snprintf(dom_name_str, STR_MAX_LENGTH, "hyperlaunch-%u", domid);
>       if (rc < 0 || rc >= STR_MAX_LENGTH)
>           return rc;
>       rc = snprintf(uuid_str, STR_MAX_LENGTH, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(uuid));
> @@ -232,7 +232,7 @@ static int init_domain(struct xs_handle *xsh,
>       int rc;
>       struct xenstore_domain_interface *intf;
>   
> -    printf("Init dom0less domain: %u\n", info->domid);
> +    printf("Init hyperlaunch domain: %u\n", info->domid);
>   
>       rc = xc_hvm_param_get(xch, info->domid, HVM_PARAM_STORE_EVTCHN,
>                             &xenstore_evtchn);
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 61e581b8c2b0..c5cb8f28011a 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -179,10 +179,10 @@ config TEE
>   source "arch/arm/tee/Kconfig"
>   
>   config STATIC_SHM
> -	bool "Statically shared memory on a dom0less system" if UNSUPPORTED
> +	bool "Statically shared memory on an Hyperlaunch system" if UNSUPPORTED
>   	depends on STATIC_MEMORY
>   	help
> -	  This option enables statically shared memory on a dom0less system.
> +	  This option enables statically shared memory on an Hyperlaunch system.
>   
>   endmenu
>   
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d0d6be922db1..897e1f2de39e 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -42,7 +42,7 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>   
>   /*
>    * If true, the extended regions support is enabled for dom0 and
> - * dom0less domUs.
> + * Hyperlaunch started domUs.
>    */
>   static bool __initdata opt_ext_regions = true;
>   boolean_param("ext_regions", opt_ext_regions);
> @@ -3347,7 +3347,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo)
>               goto err;
>       }
>   
> -    if ( kinfo->dom0less_feature & DOM0LESS_ENHANCED_NO_XS )
> +    if ( kinfo->hyperlaunch_feature & HYPERLAUNCH_ENHANCED_NO_XS )
>       {
>           ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
>           if ( ret )
> @@ -3810,7 +3810,7 @@ static int __init construct_domU(struct domain *d,
>                                    const struct dt_device_node *node)
>   {
>       struct kernel_info kinfo = {};
> -    const char *dom0less_enhanced;
> +    const char *hyperlaunch_enhanced;
>       int rc;
>       u64 mem;
>       u32 p2m_mem_mb;
> @@ -3841,18 +3841,18 @@ static int __init construct_domU(struct domain *d,
>   
>       kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
>   
> -    rc = dt_property_read_string(node, "xen,enhanced", &dom0less_enhanced);
> +    rc = dt_property_read_string(node, "xen,enhanced", &hyperlaunch_enhanced);
>       if ( rc == -EILSEQ ||
>            rc == -ENODATA ||
> -         (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) )
> +         (rc == 0 && !strcmp(hyperlaunch_enhanced, "enabled")) )
>       {
>           if ( hardware_domain )
> -            kinfo.dom0less_feature = DOM0LESS_ENHANCED;
> +            kinfo.hyperlaunch_feature = HYPERLAUNCH_ENHANCED;
>           else
>               panic("At the moment, Xenstore support requires dom0 to be present\n");
>       }
> -    else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") )
> -        kinfo.dom0less_feature = DOM0LESS_ENHANCED_NO_XS;
> +    else if ( rc == 0 && !strcmp(hyperlaunch_enhanced, "no-xenstore") )
> +        kinfo.hyperlaunch_feature = HYPERLAUNCH_ENHANCED_NO_XS;
>   
>       if ( vcpu_create(d, 0) == NULL )
>           return -ENOMEM;
> @@ -3902,7 +3902,7 @@ static int __init construct_domU(struct domain *d,
>       if ( rc < 0 )
>           return rc;
>   
> -    if ( kinfo.dom0less_feature & DOM0LESS_XENSTORE )
> +    if ( kinfo.hyperlaunch_feature & HYPERLAUNCH_XENSTORE )
>       {
>           ASSERT(hardware_domain);
>           rc = alloc_xenstore_evtchn(d);
> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> index bb64925d708c..cccf90817279 100644
> --- a/xen/arch/arm/efi/efi-boot.h
> +++ b/xen/arch/arm/efi/efi-boot.h
> @@ -807,9 +807,9 @@ static int __init handle_module_node(const EFI_LOADED_IMAGE *loaded_image,
>    * in the DT.
>    * Returns number of multiboot,module found or negative number on error.
>    */
> -static int __init handle_dom0less_domain_node(const EFI_LOADED_IMAGE *loaded_image,
> -                                              EFI_FILE_HANDLE *dir_handle,
> -                                              int domain_node)
> +static int __init
> +handle_hyperlaunch_domain_node(const EFI_LOADED_IMAGE *loaded_image,
> +                               EFI_FILE_HANDLE *dir_handle, int domain_node)
>   {
>       int module_node, addr_cells, size_cells, len;
>       const struct fdt_property *prop;
> @@ -879,7 +879,8 @@ static int __init efi_check_dt_boot(const EFI_LOADED_IMAGE *loaded_image)
>           if ( !fdt_node_check_compatible(fdt, node, "xen,domain") )
>           {
>               /* Found a node with compatible xen,domain; handle this node. */
> -            ret = handle_dom0less_domain_node(loaded_image, &dir_handle, node);
> +            ret = handle_hyperlaunch_domain_node(loaded_image, &dir_handle,
> +                                                 node);
>               if ( ret < 0 )
>                   return ERROR_DT_MODULE_DOMU;
>           }
> diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
> index 4617cdc83bac..042e250e172a 100644
> --- a/xen/arch/arm/include/asm/kernel.h
> +++ b/xen/arch/arm/include/asm/kernel.h
> @@ -10,23 +10,23 @@
>   #include <asm/setup.h>
>   
>   /*
> - * List of possible features for dom0less domUs
> + * List of possible features for Hyperlaunch started domUs
>    *
> - * DOM0LESS_ENHANCED_NO_XS: Notify the OS it is running on top of Xen. All the
> - *                          default features (excluding Xenstore) will be
> - *                          available. Note that an OS *must* not rely on the
> - *                          availability of Xen features if this is not set.
> - * DOM0LESS_XENSTORE:       Xenstore will be enabled for the VM. This feature
> - *                          can't be enabled without the
> - *                          DOM0LESS_ENHANCED_NO_XS.
> - * DOM0LESS_ENHANCED:       Notify the OS it is running on top of Xen. All the
> - *                          default features (including Xenstore) will be
> - *                          available. Note that an OS *must* not rely on the
> - *                          availability of Xen features if this is not set.
> + * HYPERLAUNCH_ENHANCED_NO_XS: Notify the OS it is running on top of Xen. All
> + *                             the default features (excluding Xenstore) will be
> + *                             available. Note that an OS *must* not rely on the
> + *                             availability of Xen features if this is not set.
> + * HYPERLAUNCH_XENSTORE:       Xenstore will be enabled for the VM. This feature
> + *                             can't be enabled without the
> + *                             HYPERLAUNCH_ENHANCED_NO_XS.
> + * HYPERLAUNCH_ENHANCED:       Notify the OS it is running on top of Xen. All
> + *                             the default features (including Xenstore) will be
> + *                             available. Note that an OS *must* not rely on the
> + *                             availability of Xen features if this is not set.
>    */
> -#define DOM0LESS_ENHANCED_NO_XS  BIT(0, U)
> -#define DOM0LESS_XENSTORE        BIT(1, U)
> -#define DOM0LESS_ENHANCED        (DOM0LESS_ENHANCED_NO_XS | DOM0LESS_XENSTORE)
> +#define HYPERLAUNCH_ENHANCED_NO_XS  BIT(0, U)
> +#define HYPERLAUNCH_XENSTORE        BIT(1, U)
> +#define HYPERLAUNCH_ENHANCED        (HYPERLAUNCH_ENHANCED_NO_XS | HYPERLAUNCH_XENSTORE)
>   
>   struct kernel_info {
>   #ifdef CONFIG_ARM_64
> @@ -57,7 +57,7 @@ struct kernel_info {
>       bool vpl011;
>   
>       /* Enable/Disable PV drivers interfaces */
> -    uint16_t dom0less_feature;
> +    uint16_t hyperlaunch_feature;
>   
>       /* GIC phandle */
>       uint32_t phandle_gic;
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index bbf72b69aae6..955c6b9e2e9e 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -1041,7 +1041,7 @@ static void __init setup_mm(void)
>   }
>   #endif
>   
> -static bool __init is_dom0less_mode(void)
> +static bool __init is_hyperlaunch_mode(void)
>   {
>       struct bootmodules *mods = &bootinfo.modules;
>       struct bootmodule *mod;
> @@ -1068,7 +1068,7 @@ static bool __init is_dom0less_mode(void)
>   
>       /*
>        * If there is no dom0 kernel but at least one domU, then we are in
> -     * dom0less mode
> +     * Hyperlaunch mode
>        */
>       return ( !dom0found && domUfound );
>   }
> @@ -1242,10 +1242,10 @@ void __init start_xen(unsigned long boot_phys_offset,
>       enable_cpu_features();
>   
>       /* Create initial domain 0. */
> -    if ( !is_dom0less_mode() )
> +    if ( !is_hyperlaunch_mode() )
>           create_dom0();
>       else
> -        printk(XENLOG_INFO "Xen dom0less mode detected\n");
> +        printk(XENLOG_INFO "Xen Hyperlaunch mode detected\n");
>   
>       if ( acpi_disabled )
>       {

-- 
Julien Grall
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Rich Persaud 10 months ago 
Hi Luca,

On Jun 30, 2023, at 05:12, Luca Fancellu <luca.fancellu@arm.com> wrote:
> 
> The "dom0less" feature was intended to be the feature where a domU
> domain could be launched without the control domain (Dom0)
> intervention, however the name seems to suggest that Dom0 cannot
> be part of the configuration, while instead it's a possible use case.

Thanks for your interest in Xen boot integrity. Please see the 2018 domB RFC:
https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01306.html

At Xen Summit 2018 (Nanjing) and Xen Summit 2019 (Chicago), OpenXT contributors made a case to Xen-on-Arm contributors for the architectural unification of incumbent dom0less (Arm) and the domB (x86) proposal for improving Xen boot integrity.

> To avoid that, rename the "dom0less" configuration with the name
> "hyperlaunch", that is less misleading.

2018-2022 work on Xen launch integrity, thanks to Apertus and Star Lab: 
https://wiki.xenproject.org/wiki/Hyperlaunch
https://www.theregister.com/2022/12/16/xen_4_17_hyperlaunch/

2023 Hyperlaunch design session last week, thanks to Apertus and AMD:
https://lists.xenproject.org/archives/html/xen-devel/2023-06/msg01870.html

> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>

If Arm is now ready to invest engineering resources into new Xen launch integrity features for security and safety-critical use cases, that is exciting news, 5 years into the on-again-off-again bootstrapped Hyperlaunch project! The roadmap would benefit from new funding.

Would you like to attend the next Xen working group call for Hyperlaunch?

Rich
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Luca Fancellu 9 months, 4 weeks ago 

> On 1 Jul 2023, at 10:07, Rich Persaud <persaur@gmail.com> wrote:
> 
> Hi Luca,
> 
> On Jun 30, 2023, at 05:12, Luca Fancellu <luca.fancellu@arm.com> wrote:
>> 
>> 
>> 
>> The "dom0less" feature was intended to be the feature where a domU
>> domain could be launched without the control domain (Dom0)
>> intervention, however the name seems to suggest that Dom0 cannot
>> be part of the configuration, while instead it's a possible use case.

Hi Rich,

> 
> Thanks for your interest in Xen boot integrity. Please see the 2018 domB RFC:
> https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01306.html
> 
> At Xen Summit 2018 (Nanjing) and Xen Summit 2019 (Chicago), OpenXT contributors made a case to Xen-on-Arm contributors for the architectural unification of incumbent dom0less (Arm) and the domB (x86) proposal for improving Xen boot integrity.
> 
>> To avoid that, rename the "dom0less" configuration with the name
>> "hyperlaunch", that is less misleading.
> 
> 2018-2022 work on Xen launch integrity, thanks to Apertus and Star Lab: 
> https://wiki.xenproject.org/wiki/Hyperlaunch
> https://www.theregister.com/2022/12/16/xen_4_17_hyperlaunch/
> 
> 2023 Hyperlaunch design session last week, thanks to Apertus and AMD:
> https://lists.xenproject.org/archives/html/xen-devel/2023-06/msg01870.html

Thank you for pointing out the history of this huge work, it is very interesting

> 
>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
> 
> If Arm is now ready to invest engineering resources into new Xen launch integrity features for security and safety-critical use cases, that is exciting news, 5 years into the on-again-off-again bootstrapped Hyperlaunch project! The roadmap would benefit from new funding.

I’m afraid that this patch is not a commitment from Arm into that, that goes above my level I’m afraid, but as part of our community work we look closely to that and I’m personally interested on the path
taken by this project.

> 
> Would you like to attend the next Xen working group call for Hyperlaunch?

I think Bertrand is already involved into it, even if unfortunately some high priority work some times take precedence.

On my side I follow the work on the ML, specifically the one related to the Arm side.

Cheers,
Luca

> 
> Rich
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Andrew Cooper 10 months ago 
On 30/06/2023 10:12 am, Luca Fancellu wrote:
> The "dom0less" feature was intended to be the feature where a domU
> domain could be launched without the control domain (Dom0)
> intervention, however the name seems to suggest that Dom0 cannot
> be part of the configuration, while instead it's a possible use case.
>
> To avoid that, rename the "dom0less" configuration with the name
> "hyperlaunch", that is less misleading.
>
> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
> ---
> This is an RFC to get the feeling of the community about the name
> change, for now it's everything in one patch just to see how it
> will look like, if there is interest on proceeding into it, I can
> split in more commit.

Have you discussed this with Dan and Chris at all?  You haven't even
CC'd them.

While there is a lot of end-goal in common between the dom0less and
hyperlaunch, and that the name dom0less is deeply misleading,
hyperlaunch is specifically not this.

~Andrew
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Luca Fancellu 10 months ago 

> On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> 
> On 30/06/2023 10:12 am, Luca Fancellu wrote:
>> The "dom0less" feature was intended to be the feature where a domU
>> domain could be launched without the control domain (Dom0)
>> intervention, however the name seems to suggest that Dom0 cannot
>> be part of the configuration, while instead it's a possible use case.
>> 
>> To avoid that, rename the "dom0less" configuration with the name
>> "hyperlaunch", that is less misleading.
>> 
>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
>> ---
>> This is an RFC to get the feeling of the community about the name
>> change, for now it's everything in one patch just to see how it
>> will look like, if there is interest on proceeding into it, I can
>> split in more commit.
> 
> Have you discussed this with Dan and Chris at all?  You haven't even
> CC'd them.

No, this rename idea started from a chat during the summit, anyway Julien
promptly add them to the CC, because I forgot.

> 
> While there is a lot of end-goal in common between the dom0less and
> hyperlaunch, and that the name dom0less is deeply misleading,
> hyperlaunch is specifically not this.

Yes Hyperlaunch is more than this, however as I said, with this RFC I would like
to ear opinions, @Daniel @Christopher could it be a proper name for the dom0less
feature?

If this patch makes things more difficult for the Hyperlunch serie, I’m ok to drop it,
my only aim was just to find a less misleading name for the feature. 

Cheers,
Luca

> 
> ~Andrew
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Daniel P. Smith 9 months, 4 weeks ago 
On 7/1/23 11:13, Luca Fancellu wrote:
> 
> 
>> On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>
>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
>>> The "dom0less" feature was intended to be the feature where a domU
>>> domain could be launched without the control domain (Dom0)
>>> intervention, however the name seems to suggest that Dom0 cannot
>>> be part of the configuration, while instead it's a possible use case.
>>>
>>> To avoid that, rename the "dom0less" configuration with the name
>>> "hyperlaunch", that is less misleading.
>>>
>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
>>> ---
>>> This is an RFC to get the feeling of the community about the name
>>> change, for now it's everything in one patch just to see how it
>>> will look like, if there is interest on proceeding into it, I can
>>> split in more commit.
>>
>> Have you discussed this with Dan and Chris at all?  You haven't even
>> CC'd them.
> 
> No, this rename idea started from a chat during the summit, anyway Julien
> promptly add them to the CC, because I forgot.

No worries and thank you for considering and taking the time to do this 
RFC. It is greatly appreciated that there is a strong willingness to 
have dom0less and hyperlaunch merged.

>>
>> While there is a lot of end-goal in common between the dom0less and
>> hyperlaunch, and that the name dom0less is deeply misleading,
>> hyperlaunch is specifically not this.
> 
> Yes Hyperlaunch is more than this, however as I said, with this RFC I would like
> to ear opinions, @Daniel @Christopher could it be a proper name for the dom0less
> feature?

As Andy has alluded, hyperlaunch is meant to provide a flexible means to 
handle domain construction at boot to meet a wide range of possible use 
cases. One of those use cases is dom0less, so yes, ultimately what 
dom0less does today will be achievable under hyperlaunch. Our intended 
approach to align the two implementations is one that is meant to be 
minimally disruptive, since dom0less is considered a supported 
(SUPPORT.md) capability. As mentioned, we are greatly appreciative to 
the openness to adopt the name, but a big concern I personally have is 
the confusion it could cause a general user. A blanket rename would end 
up with two documents in the docs tree that provide two different 
explanations of hyperlaunch and two different device tree definitions. 
So I think a more measured approach should be considered here.

> If this patch makes things more difficult for the Hyperlunch serie, I’m ok to drop it,
> my only aim was just to find a less misleading name for the feature.

What I would like to suggest as a good first step would be an update to 
the dom0less document. Provide a note at the beginning that points to 
the hyperlaunch design doc as a more general approach that will 
eventually subsume dom0less. This would provide a gentler transition for 
exist users of dom0less.

If it is not too much, I would also ask, please have a look at the 
design for boot modules in the series Christopher just posted. The 
design pulls from the work done by dom0less and expanded upon it. I 
major step into merging the two capabilities will be to have a common 
set of structures. Once those are in place, we can move to a common 
device tree representation, and at that point we would be fairly close, 
if not at the point of a formal merger of between the two.

Thank you and please let me know what you think!

v/r,
dps

> Cheers,
> Luca
> 
>>
>> ~Andrew
>
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Stefano Stabellini 9 months, 4 weeks ago 
On Mon, 3 Jul 2023, Daniel P. Smith wrote:
> On 7/1/23 11:13, Luca Fancellu wrote:
> > > On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > > 
> > > On 30/06/2023 10:12 am, Luca Fancellu wrote:
> > > > The "dom0less" feature was intended to be the feature where a domU
> > > > domain could be launched without the control domain (Dom0)
> > > > intervention, however the name seems to suggest that Dom0 cannot
> > > > be part of the configuration, while instead it's a possible use case.
> > > > 
> > > > To avoid that, rename the "dom0less" configuration with the name
> > > > "hyperlaunch", that is less misleading.
> > > > 
> > > > Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
> > > > ---
> > > > This is an RFC to get the feeling of the community about the name
> > > > change, for now it's everything in one patch just to see how it
> > > > will look like, if there is interest on proceeding into it, I can
> > > > split in more commit.
> > > 
> > > Have you discussed this with Dan and Chris at all?  You haven't even
> > > CC'd them.
> > 
> > No, this rename idea started from a chat during the summit, anyway Julien
> > promptly add them to the CC, because I forgot.
> 
> No worries and thank you for considering and taking the time to do this RFC.
> It is greatly appreciated that there is a strong willingness to have dom0less
> and hyperlaunch merged.
> 
> > > 
> > > While there is a lot of end-goal in common between the dom0less and
> > > hyperlaunch, and that the name dom0less is deeply misleading,
> > > hyperlaunch is specifically not this.
> > 
> > Yes Hyperlaunch is more than this, however as I said, with this RFC I would
> > like
> > to ear opinions, @Daniel @Christopher could it be a proper name for the
> > dom0less
> > feature?
> 
> As Andy has alluded, hyperlaunch is meant to provide a flexible means to
> handle domain construction at boot to meet a wide range of possible use cases.
> One of those use cases is dom0less, so yes, ultimately what dom0less does
> today will be achievable under hyperlaunch. Our intended approach to align the
> two implementations is one that is meant to be minimally disruptive, since
> dom0less is considered a supported (SUPPORT.md) capability. As mentioned, we
> are greatly appreciative to the openness to adopt the name,

Thanks Daniel!


> but a big concern
> I personally have is the confusion it could cause a general user. A blanket
> rename would end up with two documents in the docs tree that provide two
> different explanations of hyperlaunch and two different device tree
> definitions. So I think a more measured approach should be considered here.
>
> > If this patch makes things more difficult for the Hyperlunch serie, I’m ok
> > to drop it,
> > my only aim was just to find a less misleading name for the feature.
> 
> What I would like to suggest as a good first step would be an update to the
> dom0less document. Provide a note at the beginning that points to the
> hyperlaunch design doc as a more general approach that will eventually subsume
> dom0less. This would provide a gentler transition for exist users of dom0less.
> 
> If it is not too much, I would also ask, please have a look at the design for
> boot modules in the series Christopher just posted. The design pulls from the
> work done by dom0less and expanded upon it. I major step into merging the two
> capabilities will be to have a common set of structures. Once those are in
> place, we can move to a common device tree representation, and at that point
> we would be fairly close, if not at the point of a formal merger of between
> the two.

At the moment we have a concrete problem with explaining dom0less and
hyperlaunch to potential new users. Using two different names for a
similar feature on arm and x86 causes confusion. It is hurting Xen as a
solution. Personally I already had to switch to use the word
"hyperlaunch" for everything in my users-facing presentations.

At the summit, we discussed that it would be a good idea to use a single
name to refer to both features on arm and x86. Given that "dom0less"
causes additional issues because it makes people think that there is no
Dom0, the suggestion was to use "hyperlaunch" to refer to both features.

We don't need to 100% align the two implementations and data structures.
This is not for engineers that are going to look at the specifications
and improve them. This is for users/customers of Xen that are trying to
understand what the hypervisor enables them to do. We need to be able to
show users architecture slides with the same name and explanation on
both ARM and x86.

I am sure that Daniel and Christopher remember, but for the others on
this email thread, the name "hyperlaunch" was born exactly to be that:
the one name to cover both features on ARM and x86 even if they have a
different implementation. Appended an old email for reference.

Also I agree with Daniel that we need to be careful about the two docs
under docs/. I think he is right we need to add a paragraph explaining
the history and a pointer to the other document. Something like:

"Dom0less is the name that was used when initially introducing the
feature on ARM. Then, the "dom0less" name was retired in favor of
"hyperlaunch" to avoid confusion (a Dom0 might still be present) and to
align with x86 (where a similar feature was called hyperlaunch from the
start)."


---

Subject: [RFP] Overarching name for dom0less and DomB

Greetings,

At the DeviceTree/DomB meeting it was proposed that a new, larger
overarching name under which DomB and dom0less would be covered. There
was a general openness to the idea. As such, since Christopher and
myself are in the midst of finalizing the design document for DomB we
felt it might be better to see if a name could be selected which we
could use in the design doc in lieu of DomB. As always naming things is
hard, but after some brainstorming we believe we have arrived at a
decent name, μLaunch (micro-Launch or uLaunch).

---

μLaunch became hyperlaunch few days after, and the rest was history :-)
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Luca Fancellu 9 months, 4 weeks ago 

> On 3 Jul 2023, at 18:48, Stefano Stabellini <sstabellini@kernel.org> wrote:
> 
> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
>> On 7/1/23 11:13, Luca Fancellu wrote:
>>>> On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> 
>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
>>>>> The "dom0less" feature was intended to be the feature where a domU
>>>>> domain could be launched without the control domain (Dom0)
>>>>> intervention, however the name seems to suggest that Dom0 cannot
>>>>> be part of the configuration, while instead it's a possible use case.
>>>>> 
>>>>> To avoid that, rename the "dom0less" configuration with the name
>>>>> "hyperlaunch", that is less misleading.
>>>>> 
>>>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
>>>>> ---
>>>>> This is an RFC to get the feeling of the community about the name
>>>>> change, for now it's everything in one patch just to see how it
>>>>> will look like, if there is interest on proceeding into it, I can
>>>>> split in more commit.
>>>> 
>>>> Have you discussed this with Dan and Chris at all?  You haven't even
>>>> CC'd them.
>>> 
>>> No, this rename idea started from a chat during the summit, anyway Julien
>>> promptly add them to the CC, because I forgot.
>> 
>> No worries and thank you for considering and taking the time to do this RFC.
>> It is greatly appreciated that there is a strong willingness to have dom0less
>> and hyperlaunch merged.
>> 
>>>> 
>>>> While there is a lot of end-goal in common between the dom0less and
>>>> hyperlaunch, and that the name dom0less is deeply misleading,
>>>> hyperlaunch is specifically not this.
>>> 
>>> Yes Hyperlaunch is more than this, however as I said, with this RFC I would
>>> like
>>> to ear opinions, @Daniel @Christopher could it be a proper name for the
>>> dom0less
>>> feature?
>> 
>> As Andy has alluded, hyperlaunch is meant to provide a flexible means to
>> handle domain construction at boot to meet a wide range of possible use cases.
>> One of those use cases is dom0less, so yes, ultimately what dom0less does
>> today will be achievable under hyperlaunch. Our intended approach to align the
>> two implementations is one that is meant to be minimally disruptive, since
>> dom0less is considered a supported (SUPPORT.md) capability. As mentioned, we
>> are greatly appreciative to the openness to adopt the name,
> 
> Thanks Daniel!
> 
> 
>> but a big concern
>> I personally have is the confusion it could cause a general user. A blanket
>> rename would end up with two documents in the docs tree that provide two
>> different explanations of hyperlaunch and two different device tree
>> definitions. So I think a more measured approach should be considered here.
>> 
>>> If this patch makes things more difficult for the Hyperlunch serie, I’m ok
>>> to drop it,
>>> my only aim was just to find a less misleading name for the feature.
>> 
>> What I would like to suggest as a good first step would be an update to the
>> dom0less document. Provide a note at the beginning that points to the
>> hyperlaunch design doc as a more general approach that will eventually subsume
>> dom0less. This would provide a gentler transition for exist users of dom0less.
>> 
>> If it is not too much, I would also ask, please have a look at the design for
>> boot modules in the series Christopher just posted. The design pulls from the
>> work done by dom0less and expanded upon it. I major step into merging the two
>> capabilities will be to have a common set of structures. Once those are in
>> place, we can move to a common device tree representation, and at that point
>> we would be fairly close, if not at the point of a formal merger of between
>> the two.
> 
> At the moment we have a concrete problem with explaining dom0less and
> hyperlaunch to potential new users. Using two different names for a
> similar feature on arm and x86 causes confusion. It is hurting Xen as a
> solution. Personally I already had to switch to use the word
> "hyperlaunch" for everything in my users-facing presentations.
> 
> At the summit, we discussed that it would be a good idea to use a single
> name to refer to both features on arm and x86. Given that "dom0less"
> causes additional issues because it makes people think that there is no
> Dom0, the suggestion was to use "hyperlaunch" to refer to both features.
> 
> We don't need to 100% align the two implementations and data structures.
> This is not for engineers that are going to look at the specifications
> and improve them. This is for users/customers of Xen that are trying to
> understand what the hypervisor enables them to do. We need to be able to
> show users architecture slides with the same name and explanation on
> both ARM and x86.
> 
> I am sure that Daniel and Christopher remember, but for the others on
> this email thread, the name "hyperlaunch" was born exactly to be that:
> the one name to cover both features on ARM and x86 even if they have a
> different implementation. Appended an old email for reference.
> 
> Also I agree with Daniel that we need to be careful about the two docs
> under docs/. I think he is right we need to add a paragraph explaining
> the history and a pointer to the other document. Something like:
> 
> "Dom0less is the name that was used when initially introducing the
> feature on ARM. Then, the "dom0less" name was retired in favor of
> "hyperlaunch" to avoid confusion (a Dom0 might still be present) and to
> align with x86 (where a similar feature was called hyperlaunch from the
> start)."

I’m fully ok to add a section like this pointing to the Hyperlaunch design.

@Daniel and @Christopher would it be ok for you or the changes in the serie
are going to be problematic for your future work? In the end it’s just a mechanical
rename, so I guess we just need to agree on naming conventions.

Cheers,
Luca

> 
> 
> ---
> 
> Subject: [RFP] Overarching name for dom0less and DomB
> 
> Greetings,
> 
> At the DeviceTree/DomB meeting it was proposed that a new, larger
> overarching name under which DomB and dom0less would be covered. There
> was a general openness to the idea. As such, since Christopher and
> myself are in the midst of finalizing the design document for DomB we
> felt it might be better to see if a name could be selected which we
> could use in the design doc in lieu of DomB. As always naming things is
> hard, but after some brainstorming we believe we have arrived at a
> decent name, μLaunch (micro-Launch or uLaunch).
> 
> ---
> 
> μLaunch became hyperlaunch few days after, and the rest was history :-)
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by P S 9 months, 4 weeks ago 

> On Jul 3, 2023, at 15:45, Luca Fancellu <luca.fancellu@arm.com> wrote:
> 
> 
> 
>> On 3 Jul 2023, at 18:48, Stefano Stabellini <sstabellini@kernel.org> wrote:
>> 
>>> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
>>> On 7/1/23 11:13, Luca Fancellu wrote:
>>>>> On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>>> 
>>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
>>>>>> The "dom0less" feature was intended to be the feature where a domU
>>>>>> domain could be launched without the control domain (Dom0)
>>>>>> intervention, however the name seems to suggest that Dom0 cannot
>>>>>> be part of the configuration, while instead it's a possible use case.
>>>>>> 
>>>>>> To avoid that, rename the "dom0less" configuration with the name
>>>>>> "hyperlaunch", that is less misleading.
>>>>>> 
>>>>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
>>>>>> ---
>>>>>> This is an RFC to get the feeling of the community about the name
>>>>>> change, for now it's everything in one patch just to see how it
>>>>>> will look like, if there is interest on proceeding into it, I can
>>>>>> split in more commit.
>>>>> 
>>>>> Have you discussed this with Dan and Chris at all?  You haven't even
>>>>> CC'd them.
>>>> 
>>>> No, this rename idea started from a chat during the summit, anyway Julien
>>>> promptly add them to the CC, because I forgot.
>>> 
>>> No worries and thank you for considering and taking the time to do this RFC.
>>> It is greatly appreciated that there is a strong willingness to have dom0less
>>> and hyperlaunch merged.
>>> 
>>>>> 
>>>>> While there is a lot of end-goal in common between the dom0less and
>>>>> hyperlaunch, and that the name dom0less is deeply misleading,
>>>>> hyperlaunch is specifically not this.
>>>> 
>>>> Yes Hyperlaunch is more than this, however as I said, with this RFC I would
>>>> like
>>>> to ear opinions, @Daniel @Christopher could it be a proper name for the
>>>> dom0less
>>>> feature?
>>> 
>>> As Andy has alluded, hyperlaunch is meant to provide a flexible means to
>>> handle domain construction at boot to meet a wide range of possible use cases.
>>> One of those use cases is dom0less, so yes, ultimately what dom0less does
>>> today will be achievable under hyperlaunch. Our intended approach to align the
>>> two implementations is one that is meant to be minimally disruptive, since
>>> dom0less is considered a supported (SUPPORT.md) capability. As mentioned, we
>>> are greatly appreciative to the openness to adopt the name,
>> 
>> Thanks Daniel!
>> 
>> 
>>> but a big concern
>>> I personally have is the confusion it could cause a general user. A blanket
>>> rename would end up with two documents in the docs tree that provide two
>>> different explanations of hyperlaunch and two different device tree
>>> definitions. So I think a more measured approach should be considered here.
>>> 
>>>> If this patch makes things more difficult for the Hyperlunch serie, I’m ok
>>>> to drop it,
>>>> my only aim was just to find a less misleading name for the feature.
>>> 
>>> What I would like to suggest as a good first step would be an update to the
>>> dom0less document. Provide a note at the beginning that points to the
>>> hyperlaunch design doc as a more general approach that will eventually subsume
>>> dom0less. This would provide a gentler transition for exist users of dom0less.
>>> 
>>> If it is not too much, I would also ask, please have a look at the design for
>>> boot modules in the series Christopher just posted. The design pulls from the
>>> work done by dom0less and expanded upon it. I major step into merging the two
>>> capabilities will be to have a common set of structures. Once those are in
>>> place, we can move to a common device tree representation, and at that point
>>> we would be fairly close, if not at the point of a formal merger of between
>>> the two.
>> 
>> At the moment we have a concrete problem with explaining dom0less and
>> hyperlaunch to potential new users. Using two different names for a
>> similar feature on arm and x86 causes confusion. It is hurting Xen as a
>> solution. Personally I already had to switch to use the word
>> "hyperlaunch" for everything in my users-facing presentations.
>> 
>> At the summit, we discussed that it would be a good idea to use a single
>> name to refer to both features on arm and x86. Given that "dom0less"
>> causes additional issues because it makes people think that there is no
>> Dom0, the suggestion was to use "hyperlaunch" to refer to both features.
>> 
>> We don't need to 100% align the two implementations and data structures.
>> This is not for engineers that are going to look at the specifications
>> and improve them. This is for users/customers of Xen that are trying to
>> understand what the hypervisor enables them to do. We need to be able to
>> show users architecture slides with the same name and explanation on
>> both ARM and x86.
>> 
>> I am sure that Daniel and Christopher remember, but for the others on
>> this email thread, the name "hyperlaunch" was born exactly to be that:
>> the one name to cover both features on ARM and x86 even if they have a
>> different implementation. Appended an old email for reference.
>> 
>> Also I agree with Daniel that we need to be careful about the two docs
>> under docs/. I think he is right we need to add a paragraph explaining
>> the history and a pointer to the other document. Something like:
>> 
>> "Dom0less is the name that was used when initially introducing the
>> feature on ARM. Then, the "dom0less" name was retired in favor of
>> "hyperlaunch" to avoid confusion (a Dom0 might still be present) and to
>> align with x86 (where a similar feature was called hyperlaunch from the
>> start)."
> 
> I’m fully ok to add a section like this pointing to the Hyperlaunch design.

_If_ this text is added, please include links/references to the Hyperlaunch wiki page and Hyperlaunch design docs.

> @Daniel and @Christopher would it be ok for you or the changes in the serie
> are going to be problematic for your future work? In the end it’s just a mechanical
> rename, so I guess we just need to agree on naming conventions.

Please see the history of trademark litigation about the use of symbolic names to reference similar-but-different artifacts.  It is much easier to use the same name to refer to entirely different objects. Historically, confusion arises when a name is used in similar contexts.

There is also versioning.  Could we refer to dom0less as "Hyperlaunch Version -1"? 

How about renaming dom0less to "Hyperlaunch Lite"?

Rich

> Cheers,
> Luca
> 
>> 
>> 
>> ---
>> 
>> Subject: [RFP] Overarching name for dom0less and DomB
>> 
>> Greetings,
>> 
>> At the DeviceTree/DomB meeting it was proposed that a new, larger
>> overarching name under which DomB and dom0less would be covered. There
>> was a general openness to the idea. As such, since Christopher and
>> myself are in the midst of finalizing the design document for DomB we
>> felt it might be better to see if a name could be selected which we
>> could use in the design doc in lieu of DomB. As always naming things is
>> hard, but after some brainstorming we believe we have arrived at a
>> decent name, μLaunch (micro-Launch or uLaunch).
>> 
>> ---
>> 
>> μLaunch became hyperlaunch few days after, and the rest was history :-)
> 
>
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by George Dunlap 9 months, 3 weeks ago 
On Mon, Jul 3, 2023 at 9:55 PM P S <pairspace@gmail.com> wrote:

>
>
> > On Jul 3, 2023, at 15:45, Luca Fancellu <luca.fancellu@arm.com> wrote:
> >
> > 
> >
> >> On 3 Jul 2023, at 18:48, Stefano Stabellini <sstabellini@kernel.org>
> wrote:
> >>
> >>> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
> >>> On 7/1/23 11:13, Luca Fancellu wrote:
> >>>>> On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@citrix.com>
> wrote:
> >>>>>
> >>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
> >>>>>> The "dom0less" feature was intended to be the feature where a domU
> >>>>>> domain could be launched without the control domain (Dom0)
> >>>>>> intervention, however the name seems to suggest that Dom0 cannot
> >>>>>> be part of the configuration, while instead it's a possible use
> case.
> >>>>>>
> >>>>>> To avoid that, rename the "dom0less" configuration with the name
> >>>>>> "hyperlaunch", that is less misleading.
> >>>>>>
> >>>>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
> >>>>>> ---
> >>>>>> This is an RFC to get the feeling of the community about the name
> >>>>>> change, for now it's everything in one patch just to see how it
> >>>>>> will look like, if there is interest on proceeding into it, I can
> >>>>>> split in more commit.
> >>>>>
> >>>>> Have you discussed this with Dan and Chris at all?  You haven't even
> >>>>> CC'd them.
> >>>>
> >>>> No, this rename idea started from a chat during the summit, anyway
> Julien
> >>>> promptly add them to the CC, because I forgot.
> >>>
> >>> No worries and thank you for considering and taking the time to do
> this RFC.
> >>> It is greatly appreciated that there is a strong willingness to have
> dom0less
> >>> and hyperlaunch merged.
> >>>
> >>>>>
> >>>>> While there is a lot of end-goal in common between the dom0less and
> >>>>> hyperlaunch, and that the name dom0less is deeply misleading,
> >>>>> hyperlaunch is specifically not this.
> >>>>
> >>>> Yes Hyperlaunch is more than this, however as I said, with this RFC I
> would
> >>>> like
> >>>> to ear opinions, @Daniel @Christopher could it be a proper name for
> the
> >>>> dom0less
> >>>> feature?
> >>>
> >>> As Andy has alluded, hyperlaunch is meant to provide a flexible means
> to
> >>> handle domain construction at boot to meet a wide range of possible
> use cases.
> >>> One of those use cases is dom0less, so yes, ultimately what dom0less
> does
> >>> today will be achievable under hyperlaunch. Our intended approach to
> align the
> >>> two implementations is one that is meant to be minimally disruptive,
> since
> >>> dom0less is considered a supported (SUPPORT.md) capability. As
> mentioned, we
> >>> are greatly appreciative to the openness to adopt the name,
> >>
> >> Thanks Daniel!
> >>
> >>
> >>> but a big concern
> >>> I personally have is the confusion it could cause a general user. A
> blanket
> >>> rename would end up with two documents in the docs tree that provide
> two
> >>> different explanations of hyperlaunch and two different device tree
> >>> definitions. So I think a more measured approach should be considered
> here.
> >>>
> >>>> If this patch makes things more difficult for the Hyperlunch serie,
> I’m ok
> >>>> to drop it,
> >>>> my only aim was just to find a less misleading name for the feature.
> >>>
> >>> What I would like to suggest as a good first step would be an update
> to the
> >>> dom0less document. Provide a note at the beginning that points to the
> >>> hyperlaunch design doc as a more general approach that will eventually
> subsume
> >>> dom0less. This would provide a gentler transition for exist users of
> dom0less.
> >>>
> >>> If it is not too much, I would also ask, please have a look at the
> design for
> >>> boot modules in the series Christopher just posted. The design pulls
> from the
> >>> work done by dom0less and expanded upon it. I major step into merging
> the two
> >>> capabilities will be to have a common set of structures. Once those
> are in
> >>> place, we can move to a common device tree representation, and at that
> point
> >>> we would be fairly close, if not at the point of a formal merger of
> between
> >>> the two.
> >>
> >> At the moment we have a concrete problem with explaining dom0less and
> >> hyperlaunch to potential new users. Using two different names for a
> >> similar feature on arm and x86 causes confusion. It is hurting Xen as a
> >> solution. Personally I already had to switch to use the word
> >> "hyperlaunch" for everything in my users-facing presentations.
> >>
> >> At the summit, we discussed that it would be a good idea to use a single
> >> name to refer to both features on arm and x86. Given that "dom0less"
> >> causes additional issues because it makes people think that there is no
> >> Dom0, the suggestion was to use "hyperlaunch" to refer to both features.
> >>
> >> We don't need to 100% align the two implementations and data structures.
> >> This is not for engineers that are going to look at the specifications
> >> and improve them. This is for users/customers of Xen that are trying to
> >> understand what the hypervisor enables them to do. We need to be able to
> >> show users architecture slides with the same name and explanation on
> >> both ARM and x86.
> >>
> >> I am sure that Daniel and Christopher remember, but for the others on
> >> this email thread, the name "hyperlaunch" was born exactly to be that:
> >> the one name to cover both features on ARM and x86 even if they have a
> >> different implementation. Appended an old email for reference.
> >>
> >> Also I agree with Daniel that we need to be careful about the two docs
> >> under docs/. I think he is right we need to add a paragraph explaining
> >> the history and a pointer to the other document. Something like:
> >>
> >> "Dom0less is the name that was used when initially introducing the
> >> feature on ARM. Then, the "dom0less" name was retired in favor of
> >> "hyperlaunch" to avoid confusion (a Dom0 might still be present) and to
> >> align with x86 (where a similar feature was called hyperlaunch from the
> >> start)."
> >
> > I’m fully ok to add a section like this pointing to the Hyperlaunch
> design.
>
> _If_ this text is added, please include links/references to the
> Hyperlaunch wiki page and Hyperlaunch design docs.
>
> > @Daniel and @Christopher would it be ok for you or the changes in the
> serie
> > are going to be problematic for your future work? In the end it’s just a
> mechanical
> > rename, so I guess we just need to agree on naming conventions.
>
> Please see the history of trademark litigation about the use of symbolic
> names to reference similar-but-different artifacts.  It is much easier to
> use the same name to refer to entirely different objects. Historically,
> confusion arises when a name is used in similar contexts.
>
> There is also versioning.  Could we refer to dom0less as "Hyperlaunch
> Version -1"?
>
> How about renaming dom0less to "Hyperlaunch Lite"?
>

Perhaps it would be helpful if you could explain more clearly your
concerns.  I take it that you want a name which can be used specifically to
indicate the full "domB measured boot" functionality that was Daniel and
Christopher's original goal, and that you're afraid that using plain
"Hyperlaunch" for only the "start VMs from Xen on boot" functionality will
dilute that?

The "start VMs from Xen on boot" functionality is the *only* thing that a
big chunk of the users of this functionality want;  referring to it as
"Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the value of the
functionality.

What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured Boot" to
refer to the full measured boot functionality?

Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device Tree" (without
the involvement of a domB), "Hyperlaunch Boot Domain / Hyperlaunch domB"
for a more general "domB" functionality, and "Hyperlaunch Measured Boot"
for the full functionality (assuming there's more to this than simply
having a domB involved)?

 -George




>
> Rich
>
> > Cheers,
> > Luca
> >
> >>
> >>
> >> ---
> >>
> >> Subject: [RFP] Overarching name for dom0less and DomB
> >>
> >> Greetings,
> >>
> >> At the DeviceTree/DomB meeting it was proposed that a new, larger
> >> overarching name under which DomB and dom0less would be covered. There
> >> was a general openness to the idea. As such, since Christopher and
> >> myself are in the midst of finalizing the design document for DomB we
> >> felt it might be better to see if a name could be selected which we
> >> could use in the design doc in lieu of DomB. As always naming things is
> >> hard, but after some brainstorming we believe we have arrived at a
> >> decent name, μLaunch (micro-Launch or uLaunch).
> >>
> >> ---
> >>
> >> μLaunch became hyperlaunch few days after, and the rest was history :-)
> >
> >
>
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Stefano Stabellini 9 months, 3 weeks ago 
On Wed, 5 Jul 2023, George Dunlap wrote:
> On Mon, Jul 3, 2023 at 9:55 PM P S <pairspace@gmail.com> wrote:
>       > On Jul 3, 2023, at 15:45, Luca Fancellu <luca.fancellu@arm.com> wrote:
>       >
>       >> On 3 Jul 2023, at 18:48, Stefano Stabellini <sstabellini@kernel.org> wrote:
>       >>
>       >>> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
>       >>> On 7/1/23 11:13, Luca Fancellu wrote:
>       >>>>> On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>       >>>>>
>       >>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
>       >>>>>> The "dom0less" feature was intended to be the feature where a domU
>       >>>>>> domain could be launched without the control domain (Dom0)
>       >>>>>> intervention, however the name seems to suggest that Dom0 cannot
>       >>>>>> be part of the configuration, while instead it's a possible use case.
>       >>>>>>
>       >>>>>> To avoid that, rename the "dom0less" configuration with the name
>       >>>>>> "hyperlaunch", that is less misleading.
>       >>>>>>
>       >>>>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
>       >>>>>> ---
>       >>>>>> This is an RFC to get the feeling of the community about the name
>       >>>>>> change, for now it's everything in one patch just to see how it
>       >>>>>> will look like, if there is interest on proceeding into it, I can
>       >>>>>> split in more commit.
>       >>>>>
>       >>>>> Have you discussed this with Dan and Chris at all?  You haven't even
>       >>>>> CC'd them.
>       >>>>
>       >>>> No, this rename idea started from a chat during the summit, anyway Julien
>       >>>> promptly add them to the CC, because I forgot.
>       >>>
>       >>> No worries and thank you for considering and taking the time to do this RFC.
>       >>> It is greatly appreciated that there is a strong willingness to have dom0less
>       >>> and hyperlaunch merged.
>       >>>
>       >>>>>
>       >>>>> While there is a lot of end-goal in common between the dom0less and
>       >>>>> hyperlaunch, and that the name dom0less is deeply misleading,
>       >>>>> hyperlaunch is specifically not this.
>       >>>>
>       >>>> Yes Hyperlaunch is more than this, however as I said, with this RFC I would
>       >>>> like
>       >>>> to ear opinions, @Daniel @Christopher could it be a proper name for the
>       >>>> dom0less
>       >>>> feature?
>       >>>
>       >>> As Andy has alluded, hyperlaunch is meant to provide a flexible means to
>       >>> handle domain construction at boot to meet a wide range of possible use cases.
>       >>> One of those use cases is dom0less, so yes, ultimately what dom0less does
>       >>> today will be achievable under hyperlaunch. Our intended approach to align the
>       >>> two implementations is one that is meant to be minimally disruptive, since
>       >>> dom0less is considered a supported (SUPPORT.md) capability. As mentioned, we
>       >>> are greatly appreciative to the openness to adopt the name,
>       >>
>       >> Thanks Daniel!
>       >>
>       >>
>       >>> but a big concern
>       >>> I personally have is the confusion it could cause a general user. A blanket
>       >>> rename would end up with two documents in the docs tree that provide two
>       >>> different explanations of hyperlaunch and two different device tree
>       >>> definitions. So I think a more measured approach should be considered here.
>       >>>
>       >>>> If this patch makes things more difficult for the Hyperlunch serie, I’m ok
>       >>>> to drop it,
>       >>>> my only aim was just to find a less misleading name for the feature.
>       >>>
>       >>> What I would like to suggest as a good first step would be an update to the
>       >>> dom0less document. Provide a note at the beginning that points to the
>       >>> hyperlaunch design doc as a more general approach that will eventually subsume
>       >>> dom0less. This would provide a gentler transition for exist users of dom0less.
>       >>>
>       >>> If it is not too much, I would also ask, please have a look at the design for
>       >>> boot modules in the series Christopher just posted. The design pulls from the
>       >>> work done by dom0less and expanded upon it. I major step into merging the two
>       >>> capabilities will be to have a common set of structures. Once those are in
>       >>> place, we can move to a common device tree representation, and at that point
>       >>> we would be fairly close, if not at the point of a formal merger of between
>       >>> the two.
>       >>
>       >> At the moment we have a concrete problem with explaining dom0less and
>       >> hyperlaunch to potential new users. Using two different names for a
>       >> similar feature on arm and x86 causes confusion. It is hurting Xen as a
>       >> solution. Personally I already had to switch to use the word
>       >> "hyperlaunch" for everything in my users-facing presentations.
>       >>
>       >> At the summit, we discussed that it would be a good idea to use a single
>       >> name to refer to both features on arm and x86. Given that "dom0less"
>       >> causes additional issues because it makes people think that there is no
>       >> Dom0, the suggestion was to use "hyperlaunch" to refer to both features.
>       >>
>       >> We don't need to 100% align the two implementations and data structures.
>       >> This is not for engineers that are going to look at the specifications
>       >> and improve them. This is for users/customers of Xen that are trying to
>       >> understand what the hypervisor enables them to do. We need to be able to
>       >> show users architecture slides with the same name and explanation on
>       >> both ARM and x86.
>       >>
>       >> I am sure that Daniel and Christopher remember, but for the others on
>       >> this email thread, the name "hyperlaunch" was born exactly to be that:
>       >> the one name to cover both features on ARM and x86 even if they have a
>       >> different implementation. Appended an old email for reference.
>       >>
>       >> Also I agree with Daniel that we need to be careful about the two docs
>       >> under docs/. I think he is right we need to add a paragraph explaining
>       >> the history and a pointer to the other document. Something like:
>       >>
>       >> "Dom0less is the name that was used when initially introducing the
>       >> feature on ARM. Then, the "dom0less" name was retired in favor of
>       >> "hyperlaunch" to avoid confusion (a Dom0 might still be present) and to
>       >> align with x86 (where a similar feature was called hyperlaunch from the
>       >> start)."
>       >
>       > I’m fully ok to add a section like this pointing to the Hyperlaunch design.
> 
>       _If_ this text is added, please include links/references to the Hyperlaunch wiki page and Hyperlaunch design docs.
> 
>       > @Daniel and @Christopher would it be ok for you or the changes in the serie
>       > are going to be problematic for your future work? In the end it’s just a mechanical
>       > rename, so I guess we just need to agree on naming conventions.
> 
>       Please see the history of trademark litigation about the use of symbolic names to reference similar-but-different artifacts. 
>       It is much easier to use the same name to refer to entirely different objects. Historically, confusion arises when a name is
>       used in similar contexts.
> 
>       There is also versioning.  Could we refer to dom0less as "Hyperlaunch Version -1"?
> 
>       How about renaming dom0less to "Hyperlaunch Lite"?
> 
> 
> Perhaps it would be helpful if you could explain more clearly your concerns.  I take it that you want a name which can be used specifically
> to indicate the full "domB measured boot" functionality that was Daniel and Christopher's original goal, and that you're afraid that using
> plain "Hyperlaunch" for only the "start VMs from Xen on boot" functionality will dilute that?
> 
> The "start VMs from Xen on boot" functionality is the *only* thing that a big chunk of the users of this functionality want;  referring to
> it as "Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the value of the functionality.
> 
> What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured Boot" to refer to the full measured boot functionality?

I think this is the best way.


> Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device Tree" (without the involvement of a domB), "Hyperlaunch Boot Domain /
> Hyperlaunch domB" for a more general "domB" functionality, and "Hyperlaunch Measured Boot" for the full functionality (assuming there's
> more to this than simply having a domB involved)?


We need an overarching name to cover the feature "start VMs from Xen on
boot" on both ARM and x86. From my understanding and from the original
emails on the subject, the name "hyperlaunch" was it.

If we want to add extra things on top of "start VMs from Xen on
boot", such as TPM/SecureBoot/etc., I would suggest to call it "Measured
Hyperlaunch" or "Hyperlaunch with Measured Boot".

If you guys feel that we should reserve "Hyperlaunch" for something
else, then we need a new name for the cross-arch feature "start VMs
from Xen on boot".

That is OK, we can come up with another name that has no baggage. Not a
problem. But I don't suggest to go down this route because I think it
will cause confusion as HyperLaunch has both "hyper" and "launch" in its
name that strongly point to "start VMs from Xen on boot". Whatever other
name we could come up for "start VMs from Xen on boot", hyperlaunch will
end up getting confused with it.


We also need a way to distinguish the x86 implementation from the ARM
implementations because there are going to be differences. We'll strive
to align them as much as possible but still we are going to have some
differences in configuration options.

I think we should use "hyperlaunch" as it was intended: the overarching
name to refer to "start VMs from Xen on boot". And we should use
"hyperlaunch x86" and "hyperlaunch ARM" to distiguish between the two
implementations.
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Julien Grall 9 months, 3 weeks ago 
Hi Stefano,

On 05/07/2023 23:14, Stefano Stabellini wrote:
  > I think we should use "hyperlaunch" as it was intended: the overarching
> name to refer to "start VMs from Xen on boot". And we should use
> "hyperlaunch x86" and "hyperlaunch ARM" to distiguish between the two
> implementations.

 From my understanding is the assumption behind your proposed naming is 
every architecture will do hyperlaunch differently. That might be the 
case between x86 and arm today. But I would hope we can have the same 
features across x86 and arm in the future.

Furthermore, I highly doubt that RISC-V/PowerPC will also invent their 
own version of Hyperlaunch. Instead, they would likely re-use one of the 
existing implementations.

So I think using the architecture in the name is a short-sighted idea. 
If you want to differentiate the two implementations, then it would be 
better to use a second word that describe best the feature.

This will avoid yet another round of re-branding discussion :).

Cheers,

-- 
Julien Grall
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by George Dunlap 9 months, 3 weeks ago 
On Wed, Jul 5, 2023 at 11:14 PM Stefano Stabellini <
stefano.stabellini@amd.com> wrote:

> On Wed, 5 Jul 2023, George Dunlap wrote:
> > On Mon, Jul 3, 2023 at 9:55 PM P S <pairspace@gmail.com> wrote:
> >       > On Jul 3, 2023, at 15:45, Luca Fancellu <luca.fancellu@arm.com>
> wrote:
> >       >
> >       >> On 3 Jul 2023, at 18:48, Stefano Stabellini <
> sstabellini@kernel.org> wrote:
> >       >>
> >       >>> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
> >       >>> On 7/1/23 11:13, Luca Fancellu wrote:
> >       >>>>> On 1 Jul 2023, at 08:53, Andrew Cooper <
> andrew.cooper3@citrix.com> wrote:
> >       >>>>>
> >       >>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
> >       >>>>>> The "dom0less" feature was intended to be the feature where
> a domU
> >       >>>>>> domain could be launched without the control domain (Dom0)
> >       >>>>>> intervention, however the name seems to suggest that Dom0
> cannot
> >       >>>>>> be part of the configuration, while instead it's a possible
> use case.
> >       >>>>>>
> >       >>>>>> To avoid that, rename the "dom0less" configuration with the
> name
> >       >>>>>> "hyperlaunch", that is less misleading.
> >       >>>>>>
> >       >>>>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
> >       >>>>>> ---
> >       >>>>>> This is an RFC to get the feeling of the community about
> the name
> >       >>>>>> change, for now it's everything in one patch just to see
> how it
> >       >>>>>> will look like, if there is interest on proceeding into it,
> I can
> >       >>>>>> split in more commit.
> >       >>>>>
> >       >>>>> Have you discussed this with Dan and Chris at all?  You
> haven't even
> >       >>>>> CC'd them.
> >       >>>>
> >       >>>> No, this rename idea started from a chat during the summit,
> anyway Julien
> >       >>>> promptly add them to the CC, because I forgot.
> >       >>>
> >       >>> No worries and thank you for considering and taking the time
> to do this RFC.
> >       >>> It is greatly appreciated that there is a strong willingness
> to have dom0less
> >       >>> and hyperlaunch merged.
> >       >>>
> >       >>>>>
> >       >>>>> While there is a lot of end-goal in common between the
> dom0less and
> >       >>>>> hyperlaunch, and that the name dom0less is deeply misleading,
> >       >>>>> hyperlaunch is specifically not this.
> >       >>>>
> >       >>>> Yes Hyperlaunch is more than this, however as I said, with
> this RFC I would
> >       >>>> like
> >       >>>> to ear opinions, @Daniel @Christopher could it be a proper
> name for the
> >       >>>> dom0less
> >       >>>> feature?
> >       >>>
> >       >>> As Andy has alluded, hyperlaunch is meant to provide a
> flexible means to
> >       >>> handle domain construction at boot to meet a wide range of
> possible use cases.
> >       >>> One of those use cases is dom0less, so yes, ultimately what
> dom0less does
> >       >>> today will be achievable under hyperlaunch. Our intended
> approach to align the
> >       >>> two implementations is one that is meant to be minimally
> disruptive, since
> >       >>> dom0less is considered a supported (SUPPORT.md) capability. As
> mentioned, we
> >       >>> are greatly appreciative to the openness to adopt the name,
> >       >>
> >       >> Thanks Daniel!
> >       >>
> >       >>
> >       >>> but a big concern
> >       >>> I personally have is the confusion it could cause a general
> user. A blanket
> >       >>> rename would end up with two documents in the docs tree that
> provide two
> >       >>> different explanations of hyperlaunch and two different device
> tree
> >       >>> definitions. So I think a more measured approach should be
> considered here.
> >       >>>
> >       >>>> If this patch makes things more difficult for the Hyperlunch
> serie, I’m ok
> >       >>>> to drop it,
> >       >>>> my only aim was just to find a less misleading name for the
> feature.
> >       >>>
> >       >>> What I would like to suggest as a good first step would be an
> update to the
> >       >>> dom0less document. Provide a note at the beginning that points
> to the
> >       >>> hyperlaunch design doc as a more general approach that will
> eventually subsume
> >       >>> dom0less. This would provide a gentler transition for exist
> users of dom0less.
> >       >>>
> >       >>> If it is not too much, I would also ask, please have a look at
> the design for
> >       >>> boot modules in the series Christopher just posted. The design
> pulls from the
> >       >>> work done by dom0less and expanded upon it. I major step into
> merging the two
> >       >>> capabilities will be to have a common set of structures. Once
> those are in
> >       >>> place, we can move to a common device tree representation, and
> at that point
> >       >>> we would be fairly close, if not at the point of a formal
> merger of between
> >       >>> the two.
> >       >>
> >       >> At the moment we have a concrete problem with explaining
> dom0less and
> >       >> hyperlaunch to potential new users. Using two different names
> for a
> >       >> similar feature on arm and x86 causes confusion. It is hurting
> Xen as a
> >       >> solution. Personally I already had to switch to use the word
> >       >> "hyperlaunch" for everything in my users-facing presentations.
> >       >>
> >       >> At the summit, we discussed that it would be a good idea to use
> a single
> >       >> name to refer to both features on arm and x86. Given that
> "dom0less"
> >       >> causes additional issues because it makes people think that
> there is no
> >       >> Dom0, the suggestion was to use "hyperlaunch" to refer to both
> features.
> >       >>
> >       >> We don't need to 100% align the two implementations and data
> structures.
> >       >> This is not for engineers that are going to look at the
> specifications
> >       >> and improve them. This is for users/customers of Xen that are
> trying to
> >       >> understand what the hypervisor enables them to do. We need to
> be able to
> >       >> show users architecture slides with the same name and
> explanation on
> >       >> both ARM and x86.
> >       >>
> >       >> I am sure that Daniel and Christopher remember, but for the
> others on
> >       >> this email thread, the name "hyperlaunch" was born exactly to
> be that:
> >       >> the one name to cover both features on ARM and x86 even if they
> have a
> >       >> different implementation. Appended an old email for reference.
> >       >>
> >       >> Also I agree with Daniel that we need to be careful about the
> two docs
> >       >> under docs/. I think he is right we need to add a paragraph
> explaining
> >       >> the history and a pointer to the other document. Something like:
> >       >>
> >       >> "Dom0less is the name that was used when initially introducing
> the
> >       >> feature on ARM. Then, the "dom0less" name was retired in favor
> of
> >       >> "hyperlaunch" to avoid confusion (a Dom0 might still be
> present) and to
> >       >> align with x86 (where a similar feature was called hyperlaunch
> from the
> >       >> start)."
> >       >
> >       > I’m fully ok to add a section like this pointing to the
> Hyperlaunch design.
> >
> >       _If_ this text is added, please include links/references to the
> Hyperlaunch wiki page and Hyperlaunch design docs.
> >
> >       > @Daniel and @Christopher would it be ok for you or the changes
> in the serie
> >       > are going to be problematic for your future work? In the end
> it’s just a mechanical
> >       > rename, so I guess we just need to agree on naming conventions.
> >
> >       Please see the history of trademark litigation about the use of
> symbolic names to reference similar-but-different artifacts.
> >       It is much easier to use the same name to refer to entirely
> different objects. Historically, confusion arises when a name is
> >       used in similar contexts.
> >
> >       There is also versioning.  Could we refer to dom0less as
> "Hyperlaunch Version -1"?
> >
> >       How about renaming dom0less to "Hyperlaunch Lite"?
> >
> >
> > Perhaps it would be helpful if you could explain more clearly your
> concerns.  I take it that you want a name which can be used specifically
> > to indicate the full "domB measured boot" functionality that was Daniel
> and Christopher's original goal, and that you're afraid that using
> > plain "Hyperlaunch" for only the "start VMs from Xen on boot"
> functionality will dilute that?
> >
> > The "start VMs from Xen on boot" functionality is the *only* thing that
> a big chunk of the users of this functionality want;  referring to
> > it as "Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the value of
> the functionality.
> >
> > What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured Boot" to
> refer to the full measured boot functionality?
>
> I think this is the best way.
>
>
> > Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device Tree"
> (without the involvement of a domB), "Hyperlaunch Boot Domain /
> > Hyperlaunch domB" for a more general "domB" functionality, and
> "Hyperlaunch Measured Boot" for the full functionality (assuming there's
> > more to this than simply having a domB involved)?
>
>
> We need an overarching name to cover the feature "start VMs from Xen on
> boot" on both ARM and x86. From my understanding and from the original
> emails on the subject, the name "hyperlaunch" was it.
>

Sure; but think "guitar" vs "acoustic guitar" vs "electric guitar".
"Electric guitar" is new, "guitar" covers them both, but you sometimes need
a way to specify "acoustic".  Right now target configurations we're talking
about include:

1. Booting all your domains directly from Xen using DT configurations
2. Booting a domB, which then executes some more complicated programmatic
configuration to launch VMs before disappearing
3. Doing full measured boot on the whole system using a domB.

If "Hyperlaunch" means 1-3, we not only need a way to specify that you're
talking about 3, but *also* a way to specify that you're talking about 1.
In the vast majority of cases for the foreseeable future are going to be
1.  Additionally, we want to make sure that "Hyperlaunch" *actually* turns
out to mean 1-3, and not just 1.

The thing I like about "Hyperlaunch DT" is that to me it sounds pretty cool
but also is very descriptive: I haven't talked to people building these
systems, but it seems like saying, "The hypervisor launches VMs based on a
Device Tree passed to it at boot" will be immediately understood, and stick
in people's minds.

So maybe informally, or in "short usage" use "Hyperlaunch", but in
documentation or reference systems, when talking specifically about #1, try
to use "Hyperlaunch DT", just to reinforce the idea that there's more to
Hyperlaunch that's coming down the road?

 -George
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Stefano Stabellini 9 months, 3 weeks ago 
On Thu, 6 Jul 2023, George Dunlap wrote:
> On Wed, Jul 5, 2023 at 11:14 PM Stefano Stabellini <stefano.stabellini@amd.com> wrote:
>       On Wed, 5 Jul 2023, George Dunlap wrote:
>       > On Mon, Jul 3, 2023 at 9:55 PM P S <pairspace@gmail.com> wrote:
>       >       > On Jul 3, 2023, at 15:45, Luca Fancellu <luca.fancellu@arm.com> wrote:
>       >       >
>       >       >> On 3 Jul 2023, at 18:48, Stefano Stabellini <sstabellini@kernel.org> wrote:
>       >       >>
>       >       >>> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
>       >       >>> On 7/1/23 11:13, Luca Fancellu wrote:
>       >       >>>>> On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>       >       >>>>>
>       >       >>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
>       >       >>>>>> The "dom0less" feature was intended to be the feature where a domU
>       >       >>>>>> domain could be launched without the control domain (Dom0)
>       >       >>>>>> intervention, however the name seems to suggest that Dom0 cannot
>       >       >>>>>> be part of the configuration, while instead it's a possible use case.
>       >       >>>>>>
>       >       >>>>>> To avoid that, rename the "dom0less" configuration with the name
>       >       >>>>>> "hyperlaunch", that is less misleading.
>       >       >>>>>>
>       >       >>>>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
>       >       >>>>>> ---
>       >       >>>>>> This is an RFC to get the feeling of the community about the name
>       >       >>>>>> change, for now it's everything in one patch just to see how it
>       >       >>>>>> will look like, if there is interest on proceeding into it, I can
>       >       >>>>>> split in more commit.
>       >       >>>>>
>       >       >>>>> Have you discussed this with Dan and Chris at all?  You haven't even
>       >       >>>>> CC'd them.
>       >       >>>>
>       >       >>>> No, this rename idea started from a chat during the summit, anyway Julien
>       >       >>>> promptly add them to the CC, because I forgot.
>       >       >>>
>       >       >>> No worries and thank you for considering and taking the time to do this RFC.
>       >       >>> It is greatly appreciated that there is a strong willingness to have dom0less
>       >       >>> and hyperlaunch merged.
>       >       >>>
>       >       >>>>>
>       >       >>>>> While there is a lot of end-goal in common between the dom0less and
>       >       >>>>> hyperlaunch, and that the name dom0less is deeply misleading,
>       >       >>>>> hyperlaunch is specifically not this.
>       >       >>>>
>       >       >>>> Yes Hyperlaunch is more than this, however as I said, with this RFC I would
>       >       >>>> like
>       >       >>>> to ear opinions, @Daniel @Christopher could it be a proper name for the
>       >       >>>> dom0less
>       >       >>>> feature?
>       >       >>>
>       >       >>> As Andy has alluded, hyperlaunch is meant to provide a flexible means to
>       >       >>> handle domain construction at boot to meet a wide range of possible use cases.
>       >       >>> One of those use cases is dom0less, so yes, ultimately what dom0less does
>       >       >>> today will be achievable under hyperlaunch. Our intended approach to align the
>       >       >>> two implementations is one that is meant to be minimally disruptive, since
>       >       >>> dom0less is considered a supported (SUPPORT.md) capability. As mentioned, we
>       >       >>> are greatly appreciative to the openness to adopt the name,
>       >       >>
>       >       >> Thanks Daniel!
>       >       >>
>       >       >>
>       >       >>> but a big concern
>       >       >>> I personally have is the confusion it could cause a general user. A blanket
>       >       >>> rename would end up with two documents in the docs tree that provide two
>       >       >>> different explanations of hyperlaunch and two different device tree
>       >       >>> definitions. So I think a more measured approach should be considered here.
>       >       >>>
>       >       >>>> If this patch makes things more difficult for the Hyperlunch serie, I’m ok
>       >       >>>> to drop it,
>       >       >>>> my only aim was just to find a less misleading name for the feature.
>       >       >>>
>       >       >>> What I would like to suggest as a good first step would be an update to the
>       >       >>> dom0less document. Provide a note at the beginning that points to the
>       >       >>> hyperlaunch design doc as a more general approach that will eventually subsume
>       >       >>> dom0less. This would provide a gentler transition for exist users of dom0less.
>       >       >>>
>       >       >>> If it is not too much, I would also ask, please have a look at the design for
>       >       >>> boot modules in the series Christopher just posted. The design pulls from the
>       >       >>> work done by dom0less and expanded upon it. I major step into merging the two
>       >       >>> capabilities will be to have a common set of structures. Once those are in
>       >       >>> place, we can move to a common device tree representation, and at that point
>       >       >>> we would be fairly close, if not at the point of a formal merger of between
>       >       >>> the two.
>       >       >>
>       >       >> At the moment we have a concrete problem with explaining dom0less and
>       >       >> hyperlaunch to potential new users. Using two different names for a
>       >       >> similar feature on arm and x86 causes confusion. It is hurting Xen as a
>       >       >> solution. Personally I already had to switch to use the word
>       >       >> "hyperlaunch" for everything in my users-facing presentations.
>       >       >>
>       >       >> At the summit, we discussed that it would be a good idea to use a single
>       >       >> name to refer to both features on arm and x86. Given that "dom0less"
>       >       >> causes additional issues because it makes people think that there is no
>       >       >> Dom0, the suggestion was to use "hyperlaunch" to refer to both features.
>       >       >>
>       >       >> We don't need to 100% align the two implementations and data structures.
>       >       >> This is not for engineers that are going to look at the specifications
>       >       >> and improve them. This is for users/customers of Xen that are trying to
>       >       >> understand what the hypervisor enables them to do. We need to be able to
>       >       >> show users architecture slides with the same name and explanation on
>       >       >> both ARM and x86.
>       >       >>
>       >       >> I am sure that Daniel and Christopher remember, but for the others on
>       >       >> this email thread, the name "hyperlaunch" was born exactly to be that:
>       >       >> the one name to cover both features on ARM and x86 even if they have a
>       >       >> different implementation. Appended an old email for reference.
>       >       >>
>       >       >> Also I agree with Daniel that we need to be careful about the two docs
>       >       >> under docs/. I think he is right we need to add a paragraph explaining
>       >       >> the history and a pointer to the other document. Something like:
>       >       >>
>       >       >> "Dom0less is the name that was used when initially introducing the
>       >       >> feature on ARM. Then, the "dom0less" name was retired in favor of
>       >       >> "hyperlaunch" to avoid confusion (a Dom0 might still be present) and to
>       >       >> align with x86 (where a similar feature was called hyperlaunch from the
>       >       >> start)."
>       >       >
>       >       > I’m fully ok to add a section like this pointing to the Hyperlaunch design.
>       >
>       >       _If_ this text is added, please include links/references to the Hyperlaunch wiki page and Hyperlaunch design docs.
>       >
>       >       > @Daniel and @Christopher would it be ok for you or the changes in the serie
>       >       > are going to be problematic for your future work? In the end it’s just a mechanical
>       >       > rename, so I guess we just need to agree on naming conventions.
>       >
>       >       Please see the history of trademark litigation about the use of symbolic names to reference similar-but-different
>       artifacts. 
>       >       It is much easier to use the same name to refer to entirely different objects. Historically, confusion arises when a
>       name is
>       >       used in similar contexts.
>       >
>       >       There is also versioning.  Could we refer to dom0less as "Hyperlaunch Version -1"?
>       >
>       >       How about renaming dom0less to "Hyperlaunch Lite"?
>       >
>       >
>       > Perhaps it would be helpful if you could explain more clearly your concerns.  I take it that you want a name which can be
>       used specifically
>       > to indicate the full "domB measured boot" functionality that was Daniel and Christopher's original goal, and that you're
>       afraid that using
>       > plain "Hyperlaunch" for only the "start VMs from Xen on boot" functionality will dilute that?
>       >
>       > The "start VMs from Xen on boot" functionality is the *only* thing that a big chunk of the users of this functionality want; 
>       referring to
>       > it as "Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the value of the functionality.
>       >
>       > What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured Boot" to refer to the full measured boot functionality?
> 
>       I think this is the best way.
> 
> 
>       > Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device Tree" (without the involvement of a domB), "Hyperlaunch Boot
>       Domain /
>       > Hyperlaunch domB" for a more general "domB" functionality, and "Hyperlaunch Measured Boot" for the full functionality
>       (assuming there's
>       > more to this than simply having a domB involved)?
> 
> 
>       We need an overarching name to cover the feature "start VMs from Xen on
>       boot" on both ARM and x86. From my understanding and from the original
>       emails on the subject, the name "hyperlaunch" was it.
> 
> 
> Sure; but think "guitar" vs "acoustic guitar" vs "electric guitar".  "Electric guitar" is new, "guitar" covers them both, but you sometimes
> need a way to specify "acoustic".  Right now target configurations we're talking about include:
> 
> 1. Booting all your domains directly from Xen using DT configurations
> 2. Booting a domB, which then executes some more complicated programmatic configuration to launch VMs before disappearing
> 3. Doing full measured boot on the whole system using a domB.
> 
> If "Hyperlaunch" means 1-3, we not only need a way to specify that you're talking about 3, but *also* a way to specify that you're talking
> about 1.  In the vast majority of cases for the foreseeable future are going to be 1.  Additionally, we want to make sure that
> "Hyperlaunch" *actually* turns out to mean 1-3, and not just 1.
> 
> The thing I like about "Hyperlaunch DT" is that to me it sounds pretty cool but also is very descriptive: I haven't talked to people
> building these systems, but it seems like saying, "The hypervisor launches VMs based on a Device Tree passed to it at boot" will be
> immediately understood, and stick in people's minds.
> 
> So maybe informally, or in "short usage" use "Hyperlaunch", but in documentation or reference systems, when talking specifically about #1,
> try to use "Hyperlaunch DT", just to reinforce the idea that there's more to Hyperlaunch that's coming down the road?

"Hyperlaunch DT" would refer to both the x86 and ARM implementations
because they are both based on DT.

I think it is better than "Hyperlaunch Lite" but I am not a fan of
either of these two names because "DT" and "Lite" get easily lost in
presentations and discussions. For the next few years many will talk
about HyperLaunch just to refer to what is Dom0less today. So if the
goal when we say "HyperLaunch" is to bring Measure Boot or XSM to
people's minds, I don't think this will work well.

If we want to keep "Hyperlaunch" to mean 1-3 above, highlighting Measure
Boot or XSM, then I think we should consider using "Dom0less" for 1.
Yes, it is misleding, but at least it is unique, and a google search for
"dom0less" leads the user to the right results.

If we do that, we should rename "Hyperlaunch" with "Dom0less" in
docs/designs/launch/hyperlaunch.rst. That's because "Hyperlaunch" is
defined as "the ability of a hypervisor to construct and start one or
more virtual machines at system launch in a specific way", which falls
under Dom0less in this discussion.

In my opinion, it is better to have specific names for specific
features. So I would use "HyperLaunch" to mean "the ability of a
hypervisor to construct and start one or more virtual machines at system
launch in a specific way" as it is defined today.

When we add Measure Boot or XSM or other security/safety features, I
would call them out specifically. For instance, "HyperLaunch with XSM".
It is more descriptive and highlights each feature.

Note that at AMD we'll need HyperLaunch without an all-powerful Dom0,
probably with XSM. So I am not writing this because I don't think the
other features 2-3 are not important. They definitely are important.
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Christopher Clark 9 months, 3 weeks ago 
+CC members of the Hyperlaunch Working Group + participants on earlier
Hyperlaunch threads

On Thu, Jul 6, 2023 at 2:39 PM Stefano Stabellini <
stefano.stabellini@amd.com> wrote:

> On Thu, 6 Jul 2023, George Dunlap wrote:
> > On Wed, Jul 5, 2023 at 11:14 PM Stefano Stabellini <
> stefano.stabellini@amd.com> wrote:
> >       On Wed, 5 Jul 2023, George Dunlap wrote:
> >       > On Mon, Jul 3, 2023 at 9:55 PM P S <pairspace@gmail.com> wrote:
> >       >       > On Jul 3, 2023, at 15:45, Luca Fancellu <
> luca.fancellu@arm.com> wrote:
> >       >       >
> >       >       >> On 3 Jul 2023, at 18:48, Stefano Stabellini <
> sstabellini@kernel.org> wrote:
> >       >       >>
> >       >       >>> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
> >       >       >>> On 7/1/23 11:13, Luca Fancellu wrote:
> >       >       >>>>> On 1 Jul 2023, at 08:53, Andrew Cooper <
> andrew.cooper3@citrix.com> wrote:
> >       >       >>>>>
> >       >       >>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
> >       >       >>>>>> The "dom0less" feature was intended to be the
> feature where a domU
> >       >       >>>>>> domain could be launched without the control domain
> (Dom0)
> >       >       >>>>>> intervention, however the name seems to suggest
> that Dom0 cannot
> >       >       >>>>>> be part of the configuration, while instead it's a
> possible use case.
> >       >       >>>>>>
> >       >       >>>>>> To avoid that, rename the "dom0less" configuration
> with the name
> >       >       >>>>>> "hyperlaunch", that is less misleading.
> >       >       >>>>>>
> >       >       >>>>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com
> >
> >       >       >>>>>> ---
> >       >       >>>>>> This is an RFC to get the feeling of the community
> about the name
> >       >       >>>>>> change, for now it's everything in one patch just
> to see how it
> >       >       >>>>>> will look like, if there is interest on proceeding
> into it, I can
> >       >       >>>>>> split in more commit.
> >       >       >>>>>
> >       >       >>>>> Have you discussed this with Dan and Chris at all?
> You haven't even
> >       >       >>>>> CC'd them.
> >       >       >>>>
> >       >       >>>> No, this rename idea started from a chat during the
> summit, anyway Julien
> >       >       >>>> promptly add them to the CC, because I forgot.
> >       >       >>>
> >       >       >>> No worries and thank you for considering and taking
> the time to do this RFC.
> >       >       >>> It is greatly appreciated that there is a strong
> willingness to have dom0less
> >       >       >>> and hyperlaunch merged.
> >       >       >>>
> >       >       >>>>>
> >       >       >>>>> While there is a lot of end-goal in common between
> the dom0less and
> >       >       >>>>> hyperlaunch, and that the name dom0less is deeply
> misleading,
> >       >       >>>>> hyperlaunch is specifically not this.
> >       >       >>>>
> >       >       >>>> Yes Hyperlaunch is more than this, however as I said,
> with this RFC I would
> >       >       >>>> like
> >       >       >>>> to ear opinions, @Daniel @Christopher could it be a
> proper name for the
> >       >       >>>> dom0less
> >       >       >>>> feature?
> >       >       >>>
> >       >       >>> As Andy has alluded, hyperlaunch is meant to provide a
> flexible means to
> >       >       >>> handle domain construction at boot to meet a wide
> range of possible use cases.
> >       >       >>> One of those use cases is dom0less, so yes, ultimately
> what dom0less does
> >       >       >>> today will be achievable under hyperlaunch. Our
> intended approach to align the
> >       >       >>> two implementations is one that is meant to be
> minimally disruptive, since
> >       >       >>> dom0less is considered a supported (SUPPORT.md)
> capability. As mentioned, we
> >       >       >>> are greatly appreciative to the openness to adopt the
> name,
> >       >       >>
> >       >       >> Thanks Daniel!
> >       >       >>
> >       >       >>
> >       >       >>> but a big concern
> >       >       >>> I personally have is the confusion it could cause a
> general user. A blanket
> >       >       >>> rename would end up with two documents in the docs
> tree that provide two
> >       >       >>> different explanations of hyperlaunch and two
> different device tree
> >       >       >>> definitions. So I think a more measured approach
> should be considered here.
> >       >       >>>
> >       >       >>>> If this patch makes things more difficult for the
> Hyperlunch serie, I’m ok
> >       >       >>>> to drop it,
> >       >       >>>> my only aim was just to find a less misleading name
> for the feature.
> >       >       >>>
> >       >       >>> What I would like to suggest as a good first step
> would be an update to the
> >       >       >>> dom0less document. Provide a note at the beginning
> that points to the
> >       >       >>> hyperlaunch design doc as a more general approach that
> will eventually subsume
> >       >       >>> dom0less. This would provide a gentler transition for
> exist users of dom0less.
> >       >       >>>
> >       >       >>> If it is not too much, I would also ask, please have a
> look at the design for
> >       >       >>> boot modules in the series Christopher just posted.
> The design pulls from the
> >       >       >>> work done by dom0less and expanded upon it. I major
> step into merging the two
> >       >       >>> capabilities will be to have a common set of
> structures. Once those are in
> >       >       >>> place, we can move to a common device tree
> representation, and at that point
> >       >       >>> we would be fairly close, if not at the point of a
> formal merger of between
> >       >       >>> the two.
> >       >       >>
> >       >       >> At the moment we have a concrete problem with
> explaining dom0less and
> >       >       >> hyperlaunch to potential new users. Using two different
> names for a
> >       >       >> similar feature on arm and x86 causes confusion. It is
> hurting Xen as a
> >       >       >> solution. Personally I already had to switch to use the
> word
> >       >       >> "hyperlaunch" for everything in my users-facing
> presentations.
> >       >       >>
> >       >       >> At the summit, we discussed that it would be a good
> idea to use a single
> >       >       >> name to refer to both features on arm and x86. Given
> that "dom0less"
> >       >       >> causes additional issues because it makes people think
> that there is no
> >       >       >> Dom0, the suggestion was to use "hyperlaunch" to refer
> to both features.
> >       >       >>
> >       >       >> We don't need to 100% align the two implementations and
> data structures.
> >       >       >> This is not for engineers that are going to look at the
> specifications
> >       >       >> and improve them. This is for users/customers of Xen
> that are trying to
> >       >       >> understand what the hypervisor enables them to do. We
> need to be able to
> >       >       >> show users architecture slides with the same name and
> explanation on
> >       >       >> both ARM and x86.
> >       >       >>
> >       >       >> I am sure that Daniel and Christopher remember, but for
> the others on
> >       >       >> this email thread, the name "hyperlaunch" was born
> exactly to be that:
> >       >       >> the one name to cover both features on ARM and x86 even
> if they have a
> >       >       >> different implementation. Appended an old email for
> reference.
> >       >       >>
> >       >       >> Also I agree with Daniel that we need to be careful
> about the two docs
> >       >       >> under docs/. I think he is right we need to add a
> paragraph explaining
> >       >       >> the history and a pointer to the other document.
> Something like:
> >       >       >>
> >       >       >> "Dom0less is the name that was used when initially
> introducing the
> >       >       >> feature on ARM. Then, the "dom0less" name was retired
> in favor of
> >       >       >> "hyperlaunch" to avoid confusion (a Dom0 might still be
> present) and to
> >       >       >> align with x86 (where a similar feature was called
> hyperlaunch from the
> >       >       >> start)."
> >       >       >
> >       >       > I’m fully ok to add a section like this pointing to the
> Hyperlaunch design.
> >       >
> >       >       _If_ this text is added, please include links/references
> to the Hyperlaunch wiki page and Hyperlaunch design docs.
> >       >
> >       >       > @Daniel and @Christopher would it be ok for you or the
> changes in the serie
> >       >       > are going to be problematic for your future work? In the
> end it’s just a mechanical
> >       >       > rename, so I guess we just need to agree on naming
> conventions.
> >       >
> >       >       Please see the history of trademark litigation about the
> use of symbolic names to reference similar-but-different
> >       artifacts.
> >       >       It is much easier to use the same name to refer to
> entirely different objects. Historically, confusion arises when a
> >       name is
> >       >       used in similar contexts.
> >       >
> >       >       There is also versioning.  Could we refer to dom0less as
> "Hyperlaunch Version -1"?
> >       >
> >       >       How about renaming dom0less to "Hyperlaunch Lite"?
> >       >
> >       >
> >       > Perhaps it would be helpful if you could explain more clearly
> your concerns.  I take it that you want a name which can be
> >       used specifically
> >       > to indicate the full "domB measured boot" functionality that was
> Daniel and Christopher's original goal, and that you're
> >       afraid that using
> >       > plain "Hyperlaunch" for only the "start VMs from Xen on boot"
> functionality will dilute that?
> >       >
> >       > The "start VMs from Xen on boot" functionality is the *only*
> thing that a big chunk of the users of this functionality want;
> >       referring to
> >       > it as "Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the
> value of the functionality.
> >       >
> >       > What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured
> Boot" to refer to the full measured boot functionality?
> >
> >       I think this is the best way.
> >
> >
> >       > Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device
> Tree" (without the involvement of a domB), "Hyperlaunch Boot
> >       Domain /
> >       > Hyperlaunch domB" for a more general "domB" functionality, and
> "Hyperlaunch Measured Boot" for the full functionality
> >       (assuming there's
> >       > more to this than simply having a domB involved)?
> >
> >
> >       We need an overarching name to cover the feature "start VMs from
> Xen on
> >       boot" on both ARM and x86. From my understanding and from the
> original
> >       emails on the subject, the name "hyperlaunch" was it.
> >
> >
> > Sure; but think "guitar" vs "acoustic guitar" vs "electric guitar".
> "Electric guitar" is new, "guitar" covers them both, but you sometimes
> > need a way to specify "acoustic".  Right now target configurations we're
> talking about include:
> >
> > 1. Booting all your domains directly from Xen using DT configurations
> > 2. Booting a domB, which then executes some more complicated
> programmatic configuration to launch VMs before disappearing
> > 3. Doing full measured boot on the whole system using a domB.
> >
> > If "Hyperlaunch" means 1-3, we not only need a way to specify that
> you're talking about 3, but *also* a way to specify that you're talking
> > about 1.  In the vast majority of cases for the foreseeable future
> are going to be 1.  Additionally, we want to make sure that
> > "Hyperlaunch" *actually* turns out to mean 1-3, and not just 1.
> >
> > The thing I like about "Hyperlaunch DT" is that to me it sounds pretty
> cool but also is very descriptive: I haven't talked to people
> > building these systems, but it seems like saying, "The hypervisor
> launches VMs based on a Device Tree passed to it at boot" will be
> > immediately understood, and stick in people's minds.
> >
> > So maybe informally, or in "short usage" use "Hyperlaunch", but in
> documentation or reference systems, when talking specifically about #1,
> > try to use "Hyperlaunch DT", just to reinforce the idea that there's
> more to Hyperlaunch that's coming down the road?
>
> "Hyperlaunch DT" would refer to both the x86 and ARM implementations
> because they are both based on DT.
>
> I think it is better than "Hyperlaunch Lite" but I am not a fan of
> either of these two names because "DT" and "Lite" get easily lost in
> presentations and discussions. For the next few years many will talk
> about HyperLaunch just to refer to what is Dom0less today. So if the
> goal when we say "HyperLaunch" is to bring Measure Boot or XSM to
> people's minds, I don't think this will work well.
>
> If we want to keep "Hyperlaunch" to mean 1-3 above, highlighting Measure
> Boot or XSM, then I think we should consider using "Dom0less" for 1.
> Yes, it is misleding, but at least it is unique, and a google search for
> "dom0less" leads the user to the right results.
>
> If we do that, we should rename "Hyperlaunch" with "Dom0less" in
> docs/designs/launch/hyperlaunch.rst. That's because "Hyperlaunch" is
> defined as "the ability of a hypervisor to construct and start one or
> more virtual machines at system launch in a specific way", which falls
> under Dom0less in this discussion.
>
> In my opinion, it is better to have specific names for specific
> features. So I would use "HyperLaunch" to mean "the ability of a
> hypervisor to construct and start one or more virtual machines at system
> launch in a specific way" as it is defined today.
>
> When we add Measure Boot or XSM or other security/safety features, I
> would call them out specifically. For instance, "HyperLaunch with XSM".
> It is more descriptive and highlights each feature.
>
> Note that at AMD we'll need HyperLaunch without an all-powerful Dom0,
> probably with XSM. So I am not writing this because I don't think the
> other features 2-3 are not important. They definitely are important.



Thanks to all the participants in this thread for the interest in
Hyperlaunch and
the support for enabling common advanced boot functionality for Xen across
architectures.

I'm aiming to provide here a hopefully-fairly-objective overview of the
issues
being raised so that we can ensure that these are covered, and then I will
also
give my views afterwards.

------------------------------------------------------------
= Naming and communication

- Ensuring expectations are set correctly for the Hyperlaunch name
    - communicating the value of it, differentiation for Xen
    - avoiding sub-branding it for feature subsets, use cases, technologies

- Retiring the term 'dom0less'

- How to describe the "starting multiple VMs at host boot" functionality

    - How to describe further Hyperlaunch functionality beyond this
        - eg. isolation properties and relevance to critical systems
        - eg. running without a classic dom0

    - How Hyperlaunch relates to other boot functionalities and
technologies,
      including:
        - architecture-specific aspects and architecture-neutral aspects
        - Device Tree
        - boot domain
        - control domain, hardware domain, dom0
        - domain builder
        - system measurement
        - XSM
        - DRTM
        - etc.


= Migration

- Providing a forward path for existing users of dom0less functionality
across the technical changes for Hyperlaunch cross-architecture
implementation
    - document compatibility
    - support a "dom0less mode" with existing Device Tree structure
    - documentation updates to be paired with progress on code
implementation


= Community resourcing

- Supporting code review and merge of Hyperlaunch changes into Xen
    - transitioning existing Arm logic into common, including FDT

- Provision of accurate, consistent documentation materials to support
effective communication to existing and prospective users, developers and
other
stakeholders
     - Ensuring that the document structure supports ongoing maintenance:
        - Multiple use cases, structure docs accordingly: eg.
            - use case: static partitioning, critical + non-critical VMs
            - use case: measured launch with a boot domain
            - use case: fast VM start for embedded systems
        - Architecture of Hyperlaunch, relevance to other hypervisors
            - nested systems

- Design, review and agreement for common cross-architecture and
  arch-extensible interfaces, including:
    - common boot data structures
    - Device Tree structure
    - hypfs entries
    - introspection to determine hyperlaunched system status

- Development of test cases

- CI of Hyperlaunch interfaces, to ensure that it stays working

------------------------------------------------------------

Views arrived at in discussion with Rich and Daniel, and after reading the
thread contributions, follow this point.

"Hyperlaunch" is to be the common name across architectures for a flexible,
configurable boot system for coordinating the launch of multiple VMs by the
hypervisor, with a common implementation, pooling resources and development
risk across the Xen community. The interfaces are core to it.

From the Hyperlaunch design document (reviewed + committed to the tree):

"The design enables seamless transition for existing systems that require a
dom0, and provides a new general capability to build and launch alternative
configurations of virtual machines, including support for static
partitioning and accelerated start of VMs during host boot, while adhering
to the principles of least privilege. It incorporates the existing dom0less
functionality, extended to fold in the new developments from the
Hyperlaunch project, with support for both x86 and Arm platform
architectures, building upon and replacing the earlier 'late hardware
domain' feature for disaggregation of dom0.

Hyperlaunch is designed to be flexible and reusable across multiple use
cases, and our aim is to ensure that it is capable, widely exercised,
comprehensively tested, and well understood by the Xen community."

https://xenbits.xen.org/docs/4.17-testing/designs/launch/hyperlaunch.html

ie.  Hyperlaunch was created to move away from point solutions that
hard-code
specific launch configurations, isolation properties and threat models. It
isn't just about starting domains -- it is about enabling the construction
of
complex use cases runtimes for Xen. It is the result of iterative design
starting with the disaggregation for the late hardware domain, through
dom0less development and then with the comprehensive hyperlaunch design and
implementation that builds upon them both.

The current interest and investment in Hyperlaunch is driven by its
relevance
to Safety Critical systems due to the isolation properties and improvement
in the ability to certify the software -- this is closely related to but
slightly different from starting multiple VMs at host boot.

To encourage commonality and allow for future development, we should not
use architecture-specific or vendor-specific name variations, and also avoid
technology-specific name variations (eg. Device Tree or "DT").

Instead, the use case configurations should themselves be describable.

Thanks again,

Christopher
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Christopher Clark 9 months, 3 weeks ago 
+CC openxt, Jason, Marek

On Fri, Jul 7, 2023 at 2:06 PM Christopher Clark <
christopher.w.clark@gmail.com> wrote:

> +CC members of the Hyperlaunch Working Group + participants on earlier
> Hyperlaunch threads
>
> On Thu, Jul 6, 2023 at 2:39 PM Stefano Stabellini <
> stefano.stabellini@amd.com> wrote:
>
>> On Thu, 6 Jul 2023, George Dunlap wrote:
>> > On Wed, Jul 5, 2023 at 11:14 PM Stefano Stabellini <
>> stefano.stabellini@amd.com> wrote:
>> >       On Wed, 5 Jul 2023, George Dunlap wrote:
>> >       > On Mon, Jul 3, 2023 at 9:55 PM P S <pairspace@gmail.com> wrote:
>> >       >       > On Jul 3, 2023, at 15:45, Luca Fancellu <
>> luca.fancellu@arm.com> wrote:
>> >       >       >
>> >       >       >> On 3 Jul 2023, at 18:48, Stefano Stabellini <
>> sstabellini@kernel.org> wrote:
>> >       >       >>
>> >       >       >>> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
>> >       >       >>> On 7/1/23 11:13, Luca Fancellu wrote:
>> >       >       >>>>> On 1 Jul 2023, at 08:53, Andrew Cooper <
>> andrew.cooper3@citrix.com> wrote:
>> >       >       >>>>>
>> >       >       >>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
>> >       >       >>>>>> The "dom0less" feature was intended to be the
>> feature where a domU
>> >       >       >>>>>> domain could be launched without the control
>> domain (Dom0)
>> >       >       >>>>>> intervention, however the name seems to suggest
>> that Dom0 cannot
>> >       >       >>>>>> be part of the configuration, while instead it's a
>> possible use case.
>> >       >       >>>>>>
>> >       >       >>>>>> To avoid that, rename the "dom0less" configuration
>> with the name
>> >       >       >>>>>> "hyperlaunch", that is less misleading.
>> >       >       >>>>>>
>> >       >       >>>>>> Signed-off-by: Luca Fancellu <
>> luca.fancellu@arm.com>
>> >       >       >>>>>> ---
>> >       >       >>>>>> This is an RFC to get the feeling of the community
>> about the name
>> >       >       >>>>>> change, for now it's everything in one patch just
>> to see how it
>> >       >       >>>>>> will look like, if there is interest on proceeding
>> into it, I can
>> >       >       >>>>>> split in more commit.
>> >       >       >>>>>
>> >       >       >>>>> Have you discussed this with Dan and Chris at all?
>> You haven't even
>> >       >       >>>>> CC'd them.
>> >       >       >>>>
>> >       >       >>>> No, this rename idea started from a chat during the
>> summit, anyway Julien
>> >       >       >>>> promptly add them to the CC, because I forgot.
>> >       >       >>>
>> >       >       >>> No worries and thank you for considering and taking
>> the time to do this RFC.
>> >       >       >>> It is greatly appreciated that there is a strong
>> willingness to have dom0less
>> >       >       >>> and hyperlaunch merged.
>> >       >       >>>
>> >       >       >>>>>
>> >       >       >>>>> While there is a lot of end-goal in common between
>> the dom0less and
>> >       >       >>>>> hyperlaunch, and that the name dom0less is deeply
>> misleading,
>> >       >       >>>>> hyperlaunch is specifically not this.
>> >       >       >>>>
>> >       >       >>>> Yes Hyperlaunch is more than this, however as I
>> said, with this RFC I would
>> >       >       >>>> like
>> >       >       >>>> to ear opinions, @Daniel @Christopher could it be a
>> proper name for the
>> >       >       >>>> dom0less
>> >       >       >>>> feature?
>> >       >       >>>
>> >       >       >>> As Andy has alluded, hyperlaunch is meant to provide
>> a flexible means to
>> >       >       >>> handle domain construction at boot to meet a wide
>> range of possible use cases.
>> >       >       >>> One of those use cases is dom0less, so yes,
>> ultimately what dom0less does
>> >       >       >>> today will be achievable under hyperlaunch. Our
>> intended approach to align the
>> >       >       >>> two implementations is one that is meant to be
>> minimally disruptive, since
>> >       >       >>> dom0less is considered a supported (SUPPORT.md)
>> capability. As mentioned, we
>> >       >       >>> are greatly appreciative to the openness to adopt the
>> name,
>> >       >       >>
>> >       >       >> Thanks Daniel!
>> >       >       >>
>> >       >       >>
>> >       >       >>> but a big concern
>> >       >       >>> I personally have is the confusion it could cause a
>> general user. A blanket
>> >       >       >>> rename would end up with two documents in the docs
>> tree that provide two
>> >       >       >>> different explanations of hyperlaunch and two
>> different device tree
>> >       >       >>> definitions. So I think a more measured approach
>> should be considered here.
>> >       >       >>>
>> >       >       >>>> If this patch makes things more difficult for the
>> Hyperlunch serie, I’m ok
>> >       >       >>>> to drop it,
>> >       >       >>>> my only aim was just to find a less misleading name
>> for the feature.
>> >       >       >>>
>> >       >       >>> What I would like to suggest as a good first step
>> would be an update to the
>> >       >       >>> dom0less document. Provide a note at the beginning
>> that points to the
>> >       >       >>> hyperlaunch design doc as a more general approach
>> that will eventually subsume
>> >       >       >>> dom0less. This would provide a gentler transition for
>> exist users of dom0less.
>> >       >       >>>
>> >       >       >>> If it is not too much, I would also ask, please have
>> a look at the design for
>> >       >       >>> boot modules in the series Christopher just posted.
>> The design pulls from the
>> >       >       >>> work done by dom0less and expanded upon it. I major
>> step into merging the two
>> >       >       >>> capabilities will be to have a common set of
>> structures. Once those are in
>> >       >       >>> place, we can move to a common device tree
>> representation, and at that point
>> >       >       >>> we would be fairly close, if not at the point of a
>> formal merger of between
>> >       >       >>> the two.
>> >       >       >>
>> >       >       >> At the moment we have a concrete problem with
>> explaining dom0less and
>> >       >       >> hyperlaunch to potential new users. Using two
>> different names for a
>> >       >       >> similar feature on arm and x86 causes confusion. It is
>> hurting Xen as a
>> >       >       >> solution. Personally I already had to switch to use
>> the word
>> >       >       >> "hyperlaunch" for everything in my users-facing
>> presentations.
>> >       >       >>
>> >       >       >> At the summit, we discussed that it would be a good
>> idea to use a single
>> >       >       >> name to refer to both features on arm and x86. Given
>> that "dom0less"
>> >       >       >> causes additional issues because it makes people think
>> that there is no
>> >       >       >> Dom0, the suggestion was to use "hyperlaunch" to refer
>> to both features.
>> >       >       >>
>> >       >       >> We don't need to 100% align the two implementations
>> and data structures.
>> >       >       >> This is not for engineers that are going to look at
>> the specifications
>> >       >       >> and improve them. This is for users/customers of Xen
>> that are trying to
>> >       >       >> understand what the hypervisor enables them to do. We
>> need to be able to
>> >       >       >> show users architecture slides with the same name and
>> explanation on
>> >       >       >> both ARM and x86.
>> >       >       >>
>> >       >       >> I am sure that Daniel and Christopher remember, but
>> for the others on
>> >       >       >> this email thread, the name "hyperlaunch" was born
>> exactly to be that:
>> >       >       >> the one name to cover both features on ARM and x86
>> even if they have a
>> >       >       >> different implementation. Appended an old email for
>> reference.
>> >       >       >>
>> >       >       >> Also I agree with Daniel that we need to be careful
>> about the two docs
>> >       >       >> under docs/. I think he is right we need to add a
>> paragraph explaining
>> >       >       >> the history and a pointer to the other document.
>> Something like:
>> >       >       >>
>> >       >       >> "Dom0less is the name that was used when initially
>> introducing the
>> >       >       >> feature on ARM. Then, the "dom0less" name was retired
>> in favor of
>> >       >       >> "hyperlaunch" to avoid confusion (a Dom0 might still
>> be present) and to
>> >       >       >> align with x86 (where a similar feature was called
>> hyperlaunch from the
>> >       >       >> start)."
>> >       >       >
>> >       >       > I’m fully ok to add a section like this pointing to the
>> Hyperlaunch design.
>> >       >
>> >       >       _If_ this text is added, please include links/references
>> to the Hyperlaunch wiki page and Hyperlaunch design docs.
>> >       >
>> >       >       > @Daniel and @Christopher would it be ok for you or the
>> changes in the serie
>> >       >       > are going to be problematic for your future work? In
>> the end it’s just a mechanical
>> >       >       > rename, so I guess we just need to agree on naming
>> conventions.
>> >       >
>> >       >       Please see the history of trademark litigation about the
>> use of symbolic names to reference similar-but-different
>> >       artifacts.
>> >       >       It is much easier to use the same name to refer to
>> entirely different objects. Historically, confusion arises when a
>> >       name is
>> >       >       used in similar contexts.
>> >       >
>> >       >       There is also versioning.  Could we refer to dom0less as
>> "Hyperlaunch Version -1"?
>> >       >
>> >       >       How about renaming dom0less to "Hyperlaunch Lite"?
>> >       >
>> >       >
>> >       > Perhaps it would be helpful if you could explain more clearly
>> your concerns.  I take it that you want a name which can be
>> >       used specifically
>> >       > to indicate the full "domB measured boot" functionality that
>> was Daniel and Christopher's original goal, and that you're
>> >       afraid that using
>> >       > plain "Hyperlaunch" for only the "start VMs from Xen on boot"
>> functionality will dilute that?
>> >       >
>> >       > The "start VMs from Xen on boot" functionality is the *only*
>> thing that a big chunk of the users of this functionality want;
>> >       referring to
>> >       > it as "Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the
>> value of the functionality.
>> >       >
>> >       > What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured
>> Boot" to refer to the full measured boot functionality?
>> >
>> >       I think this is the best way.
>> >
>> >
>> >       > Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device
>> Tree" (without the involvement of a domB), "Hyperlaunch Boot
>> >       Domain /
>> >       > Hyperlaunch domB" for a more general "domB" functionality, and
>> "Hyperlaunch Measured Boot" for the full functionality
>> >       (assuming there's
>> >       > more to this than simply having a domB involved)?
>> >
>> >
>> >       We need an overarching name to cover the feature "start VMs from
>> Xen on
>> >       boot" on both ARM and x86. From my understanding and from the
>> original
>> >       emails on the subject, the name "hyperlaunch" was it.
>> >
>> >
>> > Sure; but think "guitar" vs "acoustic guitar" vs "electric guitar".
>> "Electric guitar" is new, "guitar" covers them both, but you sometimes
>> > need a way to specify "acoustic".  Right now target configurations
>> we're talking about include:
>> >
>> > 1. Booting all your domains directly from Xen using DT configurations
>> > 2. Booting a domB, which then executes some more complicated
>> programmatic configuration to launch VMs before disappearing
>> > 3. Doing full measured boot on the whole system using a domB.
>> >
>> > If "Hyperlaunch" means 1-3, we not only need a way to specify that
>> you're talking about 3, but *also* a way to specify that you're talking
>> > about 1.  In the vast majority of cases for the foreseeable future
>> are going to be 1.  Additionally, we want to make sure that
>> > "Hyperlaunch" *actually* turns out to mean 1-3, and not just 1.
>> >
>> > The thing I like about "Hyperlaunch DT" is that to me it sounds pretty
>> cool but also is very descriptive: I haven't talked to people
>> > building these systems, but it seems like saying, "The hypervisor
>> launches VMs based on a Device Tree passed to it at boot" will be
>> > immediately understood, and stick in people's minds.
>> >
>> > So maybe informally, or in "short usage" use "Hyperlaunch", but in
>> documentation or reference systems, when talking specifically about #1,
>> > try to use "Hyperlaunch DT", just to reinforce the idea that there's
>> more to Hyperlaunch that's coming down the road?
>>
>> "Hyperlaunch DT" would refer to both the x86 and ARM implementations
>> because they are both based on DT.
>>
>> I think it is better than "Hyperlaunch Lite" but I am not a fan of
>> either of these two names because "DT" and "Lite" get easily lost in
>> presentations and discussions. For the next few years many will talk
>> about HyperLaunch just to refer to what is Dom0less today. So if the
>> goal when we say "HyperLaunch" is to bring Measure Boot or XSM to
>> people's minds, I don't think this will work well.
>>
>> If we want to keep "Hyperlaunch" to mean 1-3 above, highlighting Measure
>> Boot or XSM, then I think we should consider using "Dom0less" for 1.
>> Yes, it is misleding, but at least it is unique, and a google search for
>> "dom0less" leads the user to the right results.
>>
>> If we do that, we should rename "Hyperlaunch" with "Dom0less" in
>> docs/designs/launch/hyperlaunch.rst. That's because "Hyperlaunch" is
>> defined as "the ability of a hypervisor to construct and start one or
>> more virtual machines at system launch in a specific way", which falls
>> under Dom0less in this discussion.
>>
>> In my opinion, it is better to have specific names for specific
>> features. So I would use "HyperLaunch" to mean "the ability of a
>> hypervisor to construct and start one or more virtual machines at system
>> launch in a specific way" as it is defined today.
>>
>> When we add Measure Boot or XSM or other security/safety features, I
>> would call them out specifically. For instance, "HyperLaunch with XSM".
>> It is more descriptive and highlights each feature.
>>
>> Note that at AMD we'll need HyperLaunch without an all-powerful Dom0,
>> probably with XSM. So I am not writing this because I don't think the
>> other features 2-3 are not important. They definitely are important.
>
>
>
> Thanks to all the participants in this thread for the interest in
> Hyperlaunch and
> the support for enabling common advanced boot functionality for Xen across
> architectures.
>
> I'm aiming to provide here a hopefully-fairly-objective overview of the
> issues
> being raised so that we can ensure that these are covered, and then I will
> also
> give my views afterwards.
>
> ------------------------------------------------------------
> = Naming and communication
>
> - Ensuring expectations are set correctly for the Hyperlaunch name
>     - communicating the value of it, differentiation for Xen
>     - avoiding sub-branding it for feature subsets, use cases, technologies
>
> - Retiring the term 'dom0less'
>
> - How to describe the "starting multiple VMs at host boot" functionality
>
>     - How to describe further Hyperlaunch functionality beyond this
>         - eg. isolation properties and relevance to critical systems
>         - eg. running without a classic dom0
>
>     - How Hyperlaunch relates to other boot functionalities and
> technologies,
>       including:
>         - architecture-specific aspects and architecture-neutral aspects
>         - Device Tree
>         - boot domain
>         - control domain, hardware domain, dom0
>         - domain builder
>         - system measurement
>         - XSM
>         - DRTM
>         - etc.
>
>
> = Migration
>
> - Providing a forward path for existing users of dom0less functionality
> across the technical changes for Hyperlaunch cross-architecture
> implementation
>     - document compatibility
>     - support a "dom0less mode" with existing Device Tree structure
>     - documentation updates to be paired with progress on code
> implementation
>
>
> = Community resourcing
>
> - Supporting code review and merge of Hyperlaunch changes into Xen
>     - transitioning existing Arm logic into common, including FDT
>
> - Provision of accurate, consistent documentation materials to support
> effective communication to existing and prospective users, developers and
> other
> stakeholders
>      - Ensuring that the document structure supports ongoing maintenance:
>         - Multiple use cases, structure docs accordingly: eg.
>             - use case: static partitioning, critical + non-critical VMs
>             - use case: measured launch with a boot domain
>             - use case: fast VM start for embedded systems
>         - Architecture of Hyperlaunch, relevance to other hypervisors
>             - nested systems
>
> - Design, review and agreement for common cross-architecture and
>   arch-extensible interfaces, including:
>     - common boot data structures
>     - Device Tree structure
>     - hypfs entries
>     - introspection to determine hyperlaunched system status
>
> - Development of test cases
>
> - CI of Hyperlaunch interfaces, to ensure that it stays working
>
> ------------------------------------------------------------
>
> Views arrived at in discussion with Rich and Daniel, and after reading the
> thread contributions, follow this point.
>
> "Hyperlaunch" is to be the common name across architectures for a flexible,
> configurable boot system for coordinating the launch of multiple VMs by the
> hypervisor, with a common implementation, pooling resources and development
> risk across the Xen community. The interfaces are core to it.
>
> From the Hyperlaunch design document (reviewed + committed to the tree):
>
> "The design enables seamless transition for existing systems that require
> a dom0, and provides a new general capability to build and launch
> alternative configurations of virtual machines, including support for
> static partitioning and accelerated start of VMs during host boot, while
> adhering to the principles of least privilege. It incorporates the existing
> dom0less functionality, extended to fold in the new developments from the
> Hyperlaunch project, with support for both x86 and Arm platform
> architectures, building upon and replacing the earlier 'late hardware
> domain' feature for disaggregation of dom0.
>
> Hyperlaunch is designed to be flexible and reusable across multiple use
> cases, and our aim is to ensure that it is capable, widely exercised,
> comprehensively tested, and well understood by the Xen community."
>
> https://xenbits.xen.org/docs/4.17-testing/designs/launch/hyperlaunch.html
>
> ie.  Hyperlaunch was created to move away from point solutions that
> hard-code
> specific launch configurations, isolation properties and threat models. It
> isn't just about starting domains -- it is about enabling the construction
> of
> complex use cases runtimes for Xen. It is the result of iterative design
> starting with the disaggregation for the late hardware domain, through
> dom0less development and then with the comprehensive hyperlaunch design and
> implementation that builds upon them both.
>
> The current interest and investment in Hyperlaunch is driven by its
> relevance
> to Safety Critical systems due to the isolation properties and improvement
> in the ability to certify the software -- this is closely related to but
> slightly different from starting multiple VMs at host boot.
>
> To encourage commonality and allow for future development, we should not
> use architecture-specific or vendor-specific name variations, and also
> avoid
> technology-specific name variations (eg. Device Tree or "DT").
>
> Instead, the use case configurations should themselves be describable.
>
> Thanks again,
>
> Christopher
>
>
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Stefano Stabellini 9 months, 3 weeks ago 
On Fri, 7 Jul 2023, Christopher Clark wrote:
> +CC openxt, Jason, Marek
> 
> On Fri, Jul 7, 2023 at 2:06 PM Christopher Clark <christopher.w.clark@gmail.com> wrote:
>       +CC members of the Hyperlaunch Working Group + participants on earlier Hyperlaunch threads
> 
> On Thu, Jul 6, 2023 at 2:39 PM Stefano Stabellini <stefano.stabellini@amd.com> wrote:
>       On Thu, 6 Jul 2023, George Dunlap wrote:
>       > On Wed, Jul 5, 2023 at 11:14 PM Stefano Stabellini <stefano.stabellini@amd.com> wrote:
>       >       On Wed, 5 Jul 2023, George Dunlap wrote:
>       >       > On Mon, Jul 3, 2023 at 9:55 PM P S <pairspace@gmail.com> wrote:
>       >       >       > On Jul 3, 2023, at 15:45, Luca Fancellu <luca.fancellu@arm.com> wrote:
>       >       >       >
>       >       >       >> On 3 Jul 2023, at 18:48, Stefano Stabellini <sstabellini@kernel.org> wrote:
>       >       >       >>
>       >       >       >>> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
>       >       >       >>> On 7/1/23 11:13, Luca Fancellu wrote:
>       >       >       >>>>> On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>       >       >       >>>>>
>       >       >       >>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
>       >       >       >>>>>> The "dom0less" feature was intended to be the feature where a domU
>       >       >       >>>>>> domain could be launched without the control domain (Dom0)
>       >       >       >>>>>> intervention, however the name seems to suggest that Dom0 cannot
>       >       >       >>>>>> be part of the configuration, while instead it's a possible use case.
>       >       >       >>>>>>
>       >       >       >>>>>> To avoid that, rename the "dom0less" configuration with the name
>       >       >       >>>>>> "hyperlaunch", that is less misleading.
>       >       >       >>>>>>
>       >       >       >>>>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
>       >       >       >>>>>> ---
>       >       >       >>>>>> This is an RFC to get the feeling of the community about the name
>       >       >       >>>>>> change, for now it's everything in one patch just to see how it
>       >       >       >>>>>> will look like, if there is interest on proceeding into it, I can
>       >       >       >>>>>> split in more commit.
>       >       >       >>>>>
>       >       >       >>>>> Have you discussed this with Dan and Chris at all?  You haven't even
>       >       >       >>>>> CC'd them.
>       >       >       >>>>
>       >       >       >>>> No, this rename idea started from a chat during the summit, anyway Julien
>       >       >       >>>> promptly add them to the CC, because I forgot.
>       >       >       >>>
>       >       >       >>> No worries and thank you for considering and taking the time to do this RFC.
>       >       >       >>> It is greatly appreciated that there is a strong willingness to have dom0less
>       >       >       >>> and hyperlaunch merged.
>       >       >       >>>
>       >       >       >>>>>
>       >       >       >>>>> While there is a lot of end-goal in common between the dom0less and
>       >       >       >>>>> hyperlaunch, and that the name dom0less is deeply misleading,
>       >       >       >>>>> hyperlaunch is specifically not this.
>       >       >       >>>>
>       >       >       >>>> Yes Hyperlaunch is more than this, however as I said, with this RFC I would
>       >       >       >>>> like
>       >       >       >>>> to ear opinions, @Daniel @Christopher could it be a proper name for the
>       >       >       >>>> dom0less
>       >       >       >>>> feature?
>       >       >       >>>
>       >       >       >>> As Andy has alluded, hyperlaunch is meant to provide a flexible means to
>       >       >       >>> handle domain construction at boot to meet a wide range of possible use cases.
>       >       >       >>> One of those use cases is dom0less, so yes, ultimately what dom0less does
>       >       >       >>> today will be achievable under hyperlaunch. Our intended approach to align the
>       >       >       >>> two implementations is one that is meant to be minimally disruptive, since
>       >       >       >>> dom0less is considered a supported (SUPPORT.md) capability. As mentioned, we
>       >       >       >>> are greatly appreciative to the openness to adopt the name,
>       >       >       >>
>       >       >       >> Thanks Daniel!
>       >       >       >>
>       >       >       >>
>       >       >       >>> but a big concern
>       >       >       >>> I personally have is the confusion it could cause a general user. A blanket
>       >       >       >>> rename would end up with two documents in the docs tree that provide two
>       >       >       >>> different explanations of hyperlaunch and two different device tree
>       >       >       >>> definitions. So I think a more measured approach should be considered here.
>       >       >       >>>
>       >       >       >>>> If this patch makes things more difficult for the Hyperlunch serie, I’m ok
>       >       >       >>>> to drop it,
>       >       >       >>>> my only aim was just to find a less misleading name for the feature.
>       >       >       >>>
>       >       >       >>> What I would like to suggest as a good first step would be an update to the
>       >       >       >>> dom0less document. Provide a note at the beginning that points to the
>       >       >       >>> hyperlaunch design doc as a more general approach that will eventually subsume
>       >       >       >>> dom0less. This would provide a gentler transition for exist users of dom0less.
>       >       >       >>>
>       >       >       >>> If it is not too much, I would also ask, please have a look at the design for
>       >       >       >>> boot modules in the series Christopher just posted. The design pulls from the
>       >       >       >>> work done by dom0less and expanded upon it. I major step into merging the two
>       >       >       >>> capabilities will be to have a common set of structures. Once those are in
>       >       >       >>> place, we can move to a common device tree representation, and at that point
>       >       >       >>> we would be fairly close, if not at the point of a formal merger of between
>       >       >       >>> the two.
>       >       >       >>
>       >       >       >> At the moment we have a concrete problem with explaining dom0less and
>       >       >       >> hyperlaunch to potential new users. Using two different names for a
>       >       >       >> similar feature on arm and x86 causes confusion. It is hurting Xen as a
>       >       >       >> solution. Personally I already had to switch to use the word
>       >       >       >> "hyperlaunch" for everything in my users-facing presentations.
>       >       >       >>
>       >       >       >> At the summit, we discussed that it would be a good idea to use a single
>       >       >       >> name to refer to both features on arm and x86. Given that "dom0less"
>       >       >       >> causes additional issues because it makes people think that there is no
>       >       >       >> Dom0, the suggestion was to use "hyperlaunch" to refer to both features.
>       >       >       >>
>       >       >       >> We don't need to 100% align the two implementations and data structures.
>       >       >       >> This is not for engineers that are going to look at the specifications
>       >       >       >> and improve them. This is for users/customers of Xen that are trying to
>       >       >       >> understand what the hypervisor enables them to do. We need to be able to
>       >       >       >> show users architecture slides with the same name and explanation on
>       >       >       >> both ARM and x86.
>       >       >       >>
>       >       >       >> I am sure that Daniel and Christopher remember, but for the others on
>       >       >       >> this email thread, the name "hyperlaunch" was born exactly to be that:
>       >       >       >> the one name to cover both features on ARM and x86 even if they have a
>       >       >       >> different implementation. Appended an old email for reference.
>       >       >       >>
>       >       >       >> Also I agree with Daniel that we need to be careful about the two docs
>       >       >       >> under docs/. I think he is right we need to add a paragraph explaining
>       >       >       >> the history and a pointer to the other document. Something like:
>       >       >       >>
>       >       >       >> "Dom0less is the name that was used when initially introducing the
>       >       >       >> feature on ARM. Then, the "dom0less" name was retired in favor of
>       >       >       >> "hyperlaunch" to avoid confusion (a Dom0 might still be present) and to
>       >       >       >> align with x86 (where a similar feature was called hyperlaunch from the
>       >       >       >> start)."
>       >       >       >
>       >       >       > I’m fully ok to add a section like this pointing to the Hyperlaunch design.
>       >       >
>       >       >       _If_ this text is added, please include links/references to the Hyperlaunch wiki page and Hyperlaunch
>       design docs.
>       >       >
>       >       >       > @Daniel and @Christopher would it be ok for you or the changes in the serie
>       >       >       > are going to be problematic for your future work? In the end it’s just a mechanical
>       >       >       > rename, so I guess we just need to agree on naming conventions.
>       >       >
>       >       >       Please see the history of trademark litigation about the use of symbolic names to reference
>       similar-but-different
>       >       artifacts. 
>       >       >       It is much easier to use the same name to refer to entirely different objects. Historically, confusion
>       arises when a
>       >       name is
>       >       >       used in similar contexts.
>       >       >
>       >       >       There is also versioning.  Could we refer to dom0less as "Hyperlaunch Version -1"?
>       >       >
>       >       >       How about renaming dom0less to "Hyperlaunch Lite"?
>       >       >
>       >       >
>       >       > Perhaps it would be helpful if you could explain more clearly your concerns.  I take it that you want a name
>       which can be
>       >       used specifically
>       >       > to indicate the full "domB measured boot" functionality that was Daniel and Christopher's original goal, and
>       that you're
>       >       afraid that using
>       >       > plain "Hyperlaunch" for only the "start VMs from Xen on boot" functionality will dilute that?
>       >       >
>       >       > The "start VMs from Xen on boot" functionality is the *only* thing that a big chunk of the users of this
>       functionality want; 
>       >       referring to
>       >       > it as "Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the value of the functionality.
>       >       >
>       >       > What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured Boot" to refer to the full measured boot
>       functionality?
>       >
>       >       I think this is the best way.
>       >
>       >
>       >       > Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device Tree" (without the involvement of a domB),
>       "Hyperlaunch Boot
>       >       Domain /
>       >       > Hyperlaunch domB" for a more general "domB" functionality, and "Hyperlaunch Measured Boot" for the full
>       functionality
>       >       (assuming there's
>       >       > more to this than simply having a domB involved)?
>       >
>       >
>       >       We need an overarching name to cover the feature "start VMs from Xen on
>       >       boot" on both ARM and x86. From my understanding and from the original
>       >       emails on the subject, the name "hyperlaunch" was it.
>       >
>       >
>       > Sure; but think "guitar" vs "acoustic guitar" vs "electric guitar".  "Electric guitar" is new, "guitar" covers them
>       both, but you sometimes
>       > need a way to specify "acoustic".  Right now target configurations we're talking about include:
>       >
>       > 1. Booting all your domains directly from Xen using DT configurations
>       > 2. Booting a domB, which then executes some more complicated programmatic configuration to launch VMs before
>       disappearing
>       > 3. Doing full measured boot on the whole system using a domB.
>       >
>       > If "Hyperlaunch" means 1-3, we not only need a way to specify that you're talking about 3, but *also* a way to specify
>       that you're talking
>       > about 1.  In the vast majority of cases for the foreseeable future are going to be 1.  Additionally, we want to make
>       sure that
>       > "Hyperlaunch" *actually* turns out to mean 1-3, and not just 1.
>       >
>       > The thing I like about "Hyperlaunch DT" is that to me it sounds pretty cool but also is very descriptive: I haven't
>       talked to people
>       > building these systems, but it seems like saying, "The hypervisor launches VMs based on a Device Tree passed to it at
>       boot" will be
>       > immediately understood, and stick in people's minds.
>       >
>       > So maybe informally, or in "short usage" use "Hyperlaunch", but in documentation or reference systems, when talking
>       specifically about #1,
>       > try to use "Hyperlaunch DT", just to reinforce the idea that there's more to Hyperlaunch that's coming down the road?
> 
>       "Hyperlaunch DT" would refer to both the x86 and ARM implementations
>       because they are both based on DT.
> 
>       I think it is better than "Hyperlaunch Lite" but I am not a fan of
>       either of these two names because "DT" and "Lite" get easily lost in
>       presentations and discussions. For the next few years many will talk
>       about HyperLaunch just to refer to what is Dom0less today. So if the
>       goal when we say "HyperLaunch" is to bring Measure Boot or XSM to
>       people's minds, I don't think this will work well.
> 
>       If we want to keep "Hyperlaunch" to mean 1-3 above, highlighting Measure
>       Boot or XSM, then I think we should consider using "Dom0less" for 1.
>       Yes, it is misleding, but at least it is unique, and a google search for
>       "dom0less" leads the user to the right results.
> 
>       If we do that, we should rename "Hyperlaunch" with "Dom0less" in
>       docs/designs/launch/hyperlaunch.rst. That's because "Hyperlaunch" is
>       defined as "the ability of a hypervisor to construct and start one or
>       more virtual machines at system launch in a specific way", which falls
>       under Dom0less in this discussion.
> 
>       In my opinion, it is better to have specific names for specific
>       features. So I would use "HyperLaunch" to mean "the ability of a
>       hypervisor to construct and start one or more virtual machines at system
>       launch in a specific way" as it is defined today.
> 
>       When we add Measure Boot or XSM or other security/safety features, I
>       would call them out specifically. For instance, "HyperLaunch with XSM".
>       It is more descriptive and highlights each feature.
> 
>       Note that at AMD we'll need HyperLaunch without an all-powerful Dom0,
>       probably with XSM. So I am not writing this because I don't think the
>       other features 2-3 are not important. They definitely are important.
> 
> 
> 
> Thanks to all the participants in this thread for the interest in Hyperlaunch and
> the support for enabling common advanced boot functionality for Xen across
> architectures.
> 
> I'm aiming to provide here a hopefully-fairly-objective overview of the issues
> being raised so that we can ensure that these are covered, and then I will also
> give my views afterwards.
> 
> ------------------------------------------------------------
> = Naming and communication
> 
> - Ensuring expectations are set correctly for the Hyperlaunch name
>     - communicating the value of it, differentiation for Xen
>     - avoiding sub-branding it for feature subsets, use cases, technologies
> 
> - Retiring the term 'dom0less'
> 
> - How to describe the "starting multiple VMs at host boot" functionality
> 
>     - How to describe further Hyperlaunch functionality beyond this
>         - eg. isolation properties and relevance to critical systems
>         - eg. running without a classic dom0
> 
>     - How Hyperlaunch relates to other boot functionalities and technologies,
>       including:
>         - architecture-specific aspects and architecture-neutral aspects
>         - Device Tree
>         - boot domain
>         - control domain, hardware domain, dom0
>         - domain builder
>         - system measurement
>         - XSM
>         - DRTM
>         - etc.
> 
> 
> = Migration
> 
> - Providing a forward path for existing users of dom0less functionality
> across the technical changes for Hyperlaunch cross-architecture implementation
>     - document compatibility
>     - support a "dom0less mode" with existing Device Tree structure
>     - documentation updates to be paired with progress on code implementation
> 
> 
> = Community resourcing
> 
> - Supporting code review and merge of Hyperlaunch changes into Xen
>     - transitioning existing Arm logic into common, including FDT
> 
> - Provision of accurate, consistent documentation materials to support
> effective communication to existing and prospective users, developers and other
> stakeholders
>      - Ensuring that the document structure supports ongoing maintenance:
>         - Multiple use cases, structure docs accordingly: eg.
>             - use case: static partitioning, critical + non-critical VMs
>             - use case: measured launch with a boot domain
>             - use case: fast VM start for embedded systems
>         - Architecture of Hyperlaunch, relevance to other hypervisors
>             - nested systems
> 
> - Design, review and agreement for common cross-architecture and
>   arch-extensible interfaces, including:
>     - common boot data structures
>     - Device Tree structure
>     - hypfs entries
>     - introspection to determine hyperlaunched system status
> 
> - Development of test cases
> 
> - CI of Hyperlaunch interfaces, to ensure that it stays working
>  
> ------------------------------------------------------------
> 
> Views arrived at in discussion with Rich and Daniel, and after reading the
> thread contributions, follow this point.
> 
> "Hyperlaunch" is to be the common name across architectures for a flexible,
> configurable boot system for coordinating the launch of multiple VMs by the
> hypervisor, with a common implementation, pooling resources and development
> risk across the Xen community. The interfaces are core to it.
> 
> From the Hyperlaunch design document (reviewed + committed to the tree):
> 
> "The design enables seamless transition for existing systems that require a dom0, and provides a new general capability to build and
> launch alternative configurations of virtual machines, including support for static partitioning and accelerated start of VMs during
> host boot, while adhering to the principles of least privilege. It incorporates the existing dom0less functionality, extended to fold
> in the new developments from the Hyperlaunch project, with support for both x86 and Arm platform architectures, building upon and
> replacing the earlier 'late hardware domain' feature for disaggregation of dom0.
> 
> Hyperlaunch is designed to be flexible and reusable across multiple use cases, and our aim is to ensure that it is capable, widely
> exercised, comprehensively tested, and well understood by the Xen community."
> 
> https://xenbits.xen.org/docs/4.17-testing/designs/launch/hyperlaunch.html
> 
> ie.  Hyperlaunch was created to move away from point solutions that hard-code
> specific launch configurations, isolation properties and threat models. It
> isn't just about starting domains -- it is about enabling the construction of
> complex use cases runtimes for Xen. It is the result of iterative design
> starting with the disaggregation for the late hardware domain, through
> dom0less development and then with the comprehensive hyperlaunch design and
> implementation that builds upon them both.
> 
> The current interest and investment in Hyperlaunch is driven by its relevance
> to Safety Critical systems due to the isolation properties and improvement
> in the ability to certify the software -- this is closely related to but
> slightly different from starting multiple VMs at host boot.
> 
> To encourage commonality and allow for future development, we should not
> use architecture-specific or vendor-specific name variations, and also avoid
> technology-specific name variations (eg. Device Tree or "DT").
> 
> Instead, the use case configurations should themselves be describable.

Thanks Christopher, Daniel and all!

So if I understand correctly, you are in favor if renaming Dom0less to
Hyperlaunch throughout the Xen codebase? And we need a clarification of
the docs/, especially docs/features/dom0less.pandoc?
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Rich Persaud 9 months, 3 weeks ago 
On Jul 7, 2023, at 21:17, Stefano Stabellini <stefano.stabellini@amd.com> wrote:
> 
> On Fri, 7 Jul 2023, Christopher Clark wrote:
>> +CC openxt, Jason, Marek
>> 
>> On Fri, Jul 7, 2023 at 2:06 PM Christopher Clark <christopher.w.clark@gmail.com> wrote:
>>      +CC members of the Hyperlaunch Working Group + participants on earlier Hyperlaunch threads
>> 
>> On Thu, Jul 6, 2023 at 2:39 PM Stefano Stabellini <stefano.stabellini@amd.com> wrote:
>>>      On Thu, 6 Jul 2023, George Dunlap wrote:
>>>> On Wed, Jul 5, 2023 at 11:14 PM Stefano Stabellini <stefano.stabellini@amd.com> wrote:
>>>>        On Wed, 5 Jul 2023, George Dunlap wrote:
>>>        > On Mon, Jul 3, 2023 at 9:55 PM P S <pairspace@gmail.com> wrote:
>>>        >       > On Jul 3, 2023, at 15:45, Luca Fancellu <luca.fancellu@arm.com> wrote:
>>>        >       >
>>>        >       >> On 3 Jul 2023, at 18:48, Stefano Stabellini <sstabellini@kernel.org> wrote:
>>>        >       >>
>>>        >       >>> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
>>>        >       >>> On 7/1/23 11:13, Luca Fancellu wrote:
>>>        >       >>>>> On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>        >       >>>>>
>>>        >       >>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
>>>        >       >>>>>> The "dom0less" feature was intended to be the feature where a domU
>>>        >       >>>>>> domain could be launched without the control domain (Dom0)
>>>        >       >>>>>> intervention, however the name seems to suggest that Dom0 cannot
>>>        >       >>>>>> be part of the configuration, while instead it's a possible use case.
>>>        >       >>>>>>
>>>        >       >>>>>> To avoid that, rename the "dom0less" configuration with the name
>>>        >       >>>>>> "hyperlaunch", that is less misleading.
>>>        >       >>>>>>
>>>        >       >>>>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
>>>        >       >>>>>> ---
>>>        >       >>>>>> This is an RFC to get the feeling of the community about the name
>>>        >       >>>>>> change, for now it's everything in one patch just to see how it
>>>        >       >>>>>> will look like, if there is interest on proceeding into it, I can
>>>        >       >>>>>> split in more commit.
>>>        >       >>>>>
>>>        >       >>>>> Have you discussed this with Dan and Chris at all?  You haven't even
>>>        >       >>>>> CC'd them.
>>>        >       >>>>
>>>        >       >>>> No, this rename idea started from a chat during the summit, anyway Julien
>>>        >       >>>> promptly add them to the CC, because I forgot.
>>>        >       >>>
>>>        >       >>> No worries and thank you for considering and taking the time to do this RFC.
>>>        >       >>> It is greatly appreciated that there is a strong willingness to have dom0less
>>>        >       >>> and hyperlaunch merged.
>>>        >       >>>
>>>        >       >>>>>
>>>        >       >>>>> While there is a lot of end-goal in common between the dom0less and
>>>        >       >>>>> hyperlaunch, and that the name dom0less is deeply misleading,
>>>        >       >>>>> hyperlaunch is specifically not this.
>>>        >       >>>>
>>>        >       >>>> Yes Hyperlaunch is more than this, however as I said, with this RFC I would
>>>        >       >>>> like
>>>        >       >>>> to ear opinions, @Daniel @Christopher could it be a proper name for the
>>>        >       >>>> dom0less
>>>        >       >>>> feature?
>>>        >       >>>
>>>        >       >>> As Andy has alluded, hyperlaunch is meant to provide a flexible means to
>>>        >       >>> handle domain construction at boot to meet a wide range of possible use cases.
>>>        >       >>> One of those use cases is dom0less, so yes, ultimately what dom0less does
>>>        >       >>> today will be achievable under hyperlaunch. Our intended approach to align the
>>>        >       >>> two implementations is one that is meant to be minimally disruptive, since
>>>        >       >>> dom0less is considered a supported (SUPPORT.md) capability. As mentioned, we
>>>        >       >>> are greatly appreciative to the openness to adopt the name,
>>>        >       >>
>>>        >       >> Thanks Daniel!
>>>        >       >>
>>>        >       >>
>>>        >       >>> but a big concern
>>>        >       >>> I personally have is the confusion it could cause a general user. A blanket
>>>        >       >>> rename would end up with two documents in the docs tree that provide two
>>>        >       >>> different explanations of hyperlaunch and two different device tree
>>>        >       >>> definitions. So I think a more measured approach should be considered here.
>>>        >       >>>
>>>        >       >>>> If this patch makes things more difficult for the Hyperlunch serie, I’m ok
>>>        >       >>>> to drop it,
>>>        >       >>>> my only aim was just to find a less misleading name for the feature.
>>>        >       >>>
>>>        >       >>> What I would like to suggest as a good first step would be an update to the
>>>        >       >>> dom0less document. Provide a note at the beginning that points to the
>>>        >       >>> hyperlaunch design doc as a more general approach that will eventually subsume
>>>        >       >>> dom0less. This would provide a gentler transition for exist users of dom0less.
>>>        >       >>>
>>>        >       >>> If it is not too much, I would also ask, please have a look at the design for
>>>        >       >>> boot modules in the series Christopher just posted. The design pulls from the
>>>        >       >>> work done by dom0less and expanded upon it. I major step into merging the two
>>>        >       >>> capabilities will be to have a common set of structures. Once those are in
>>>        >       >>> place, we can move to a common device tree representation, and at that point
>>>        >       >>> we would be fairly close, if not at the point of a formal merger of between
>>>        >       >>> the two.
>>>        >       >>
>>>        >       >> At the moment we have a concrete problem with explaining dom0less and
>>>        >       >> hyperlaunch to potential new users. Using two different names for a
>>>        >       >> similar feature on arm and x86 causes confusion. It is hurting Xen as a
>>>        >       >> solution. Personally I already had to switch to use the word
>>>        >       >> "hyperlaunch" for everything in my users-facing presentations.
>>>        >       >>
>>>        >       >> At the summit, we discussed that it would be a good idea to use a single
>>>        >       >> name to refer to both features on arm and x86. Given that "dom0less"
>>>        >       >> causes additional issues because it makes people think that there is no
>>>        >       >> Dom0, the suggestion was to use "hyperlaunch" to refer to both features.
>>>        >       >>
>>>        >       >> We don't need to 100% align the two implementations and data structures.
>>>        >       >> This is not for engineers that are going to look at the specifications
>>>        >       >> and improve them. This is for users/customers of Xen that are trying to
>>>        >       >> understand what the hypervisor enables them to do. We need to be able to
>>>        >       >> show users architecture slides with the same name and explanation on
>>>        >       >> both ARM and x86.
>>>        >       >>
>>>        >       >> I am sure that Daniel and Christopher remember, but for the others on
>>>        >       >> this email thread, the name "hyperlaunch" was born exactly to be that:
>>>        >       >> the one name to cover both features on ARM and x86 even if they have a
>>>        >       >> different implementation. Appended an old email for reference.
>>>        >       >>
>>>        >       >> Also I agree with Daniel that we need to be careful about the two docs
>>>        >       >> under docs/. I think he is right we need to add a paragraph explaining
>>>        >       >> the history and a pointer to the other document. Something like:
>>>        >       >>
>>>        >       >> "Dom0less is the name that was used when initially introducing the
>>>        >       >> feature on ARM. Then, the "dom0less" name was retired in favor of
>>>        >       >> "hyperlaunch" to avoid confusion (a Dom0 might still be present) and to
>>>        >       >> align with x86 (where a similar feature was called hyperlaunch from the
>>>        >       >> start)."
>>>        >       >
>>>        >       > I’m fully ok to add a section like this pointing to the Hyperlaunch design.
>>>        >
>>>        >       _If_ this text is added, please include links/references to the Hyperlaunch wiki page and Hyperlaunch
>>      design docs.
>>>        >
>>>        >       > @Daniel and @Christopher would it be ok for you or the changes in the serie
>>>        >       > are going to be problematic for your future work? In the end it’s just a mechanical
>>>        >       > rename, so I guess we just need to agree on naming conventions.
>>>        >
>>>        >       Please see the history of trademark litigation about the use of symbolic names to reference
>>      similar-but-different
>>>        artifacts. 
>>>        >       It is much easier to use the same name to refer to entirely different objects. Historically, confusion
>>      arises when a
>>>        name is
>>>        >       used in similar contexts.
>>>        >
>>>        >       There is also versioning.  Could we refer to dom0less as "Hyperlaunch Version -1"?
>>>        >
>>>        >       How about renaming dom0less to "Hyperlaunch Lite"?
>>>        >
>>>        >
>>>        > Perhaps it would be helpful if you could explain more clearly your concerns.  I take it that you want a name
>>      which can be
>>>        used specifically
>>>        > to indicate the full "domB measured boot" functionality that was Daniel and Christopher's original goal, and
>>      that you're
>>>        afraid that using
>>>        > plain "Hyperlaunch" for only the "start VMs from Xen on boot" functionality will dilute that?
>>>        >
>>>        > The "start VMs from Xen on boot" functionality is the *only* thing that a big chunk of the users of this
>>      functionality want; 
>>>        referring to
>>>        > it as "Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the value of the functionality.
>>>        >
>>>        > What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured Boot" to refer to the full measured boot
>>      functionality?
>>> 
>>>        I think this is the best way.
>>> 
>>> 
>>>        > Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device Tree" (without the involvement of a domB),
>>      "Hyperlaunch Boot
>>>        Domain /
>>>        > Hyperlaunch domB" for a more general "domB" functionality, and "Hyperlaunch Measured Boot" for the full
>>      functionality
>>>        (assuming there's
>>>        > more to this than simply having a domB involved)?
>>> 
>>> 
>>>        We need an overarching name to cover the feature "start VMs from Xen on
>>>        boot" on both ARM and x86. From my understanding and from the original
>>>        emails on the subject, the name "hyperlaunch" was it.
>>> 
>>> 
>>> Sure; but think "guitar" vs "acoustic guitar" vs "electric guitar".  "Electric guitar" is new, "guitar" covers them
>>      both, but you sometimes
>>> need a way to specify "acoustic".  Right now target configurations we're talking about include:
>>> 
>>> 1. Booting all your domains directly from Xen using DT configurations
>>> 2. Booting a domB, which then executes some more complicated programmatic configuration to launch VMs before
>>      disappearing
>>> 3. Doing full measured boot on the whole system using a domB.
>>> 
>>> If "Hyperlaunch" means 1-3, we not only need a way to specify that you're talking about 3, but *also* a way to specify
>>      that you're talking
>>> about 1.  In the vast majority of cases for the foreseeable future are going to be 1.  Additionally, we want to make
>>      sure that
>>> "Hyperlaunch" *actually* turns out to mean 1-3, and not just 1.
>>> 
>>> The thing I like about "Hyperlaunch DT" is that to me it sounds pretty cool but also is very descriptive: I haven't
>>      talked to people
>>> building these systems, but it seems like saying, "The hypervisor launches VMs based on a Device Tree passed to it at
>>      boot" will be
>>> immediately understood, and stick in people's minds.
>>> 
>>> So maybe informally, or in "short usage" use "Hyperlaunch", but in documentation or reference systems, when talking
>>      specifically about #1,
>>> try to use "Hyperlaunch DT", just to reinforce the idea that there's more to Hyperlaunch that's coming down the road?
>> 
>>      "Hyperlaunch DT" would refer to both the x86 and ARM implementations
>>      because they are both based on DT.
>> 
>>      I think it is better than "Hyperlaunch Lite" but I am not a fan of
>>      either of these two names because "DT" and "Lite" get easily lost in
>>      presentations and discussions. For the next few years many will talk
>>      about HyperLaunch just to refer to what is Dom0less today. So if the
>>      goal when we say "HyperLaunch" is to bring Measure Boot or XSM to
>>      people's minds, I don't think this will work well.
>> 
>>      If we want to keep "Hyperlaunch" to mean 1-3 above, highlighting Measure
>>      Boot or XSM, then I think we should consider using "Dom0less" for 1.
>>      Yes, it is misleding, but at least it is unique, and a google search for
>>      "dom0less" leads the user to the right results.
>> 
>>      If we do that, we should rename "Hyperlaunch" with "Dom0less" in
>>      docs/designs/launch/hyperlaunch.rst. That's because "Hyperlaunch" is
>>      defined as "the ability of a hypervisor to construct and start one or
>>      more virtual machines at system launch in a specific way", which falls
>>      under Dom0less in this discussion.
>> 
>>      In my opinion, it is better to have specific names for specific
>>      features. So I would use "HyperLaunch" to mean "the ability of a
>>      hypervisor to construct and start one or more virtual machines at system
>>      launch in a specific way" as it is defined today.
>> 
>>      When we add Measure Boot or XSM or other security/safety features, I
>>      would call them out specifically. For instance, "HyperLaunch with XSM".
>>      It is more descriptive and highlights each feature.
>> 
>>      Note that at AMD we'll need HyperLaunch without an all-powerful Dom0,
>>      probably with XSM. So I am not writing this because I don't think the
>>      other features 2-3 are not important. They definitely are important.
>> 
>> 
>> 
>> Thanks to all the participants in this thread for the interest in Hyperlaunch and
>> the support for enabling common advanced boot functionality for Xen across
>> architectures.
>> 
>> I'm aiming to provide here a hopefully-fairly-objective overview of the issues
>> being raised so that we can ensure that these are covered, and then I will also
>> give my views afterwards.
>> 
>> ------------------------------------------------------------
>> = Naming and communication
>> 
>> - Ensuring expectations are set correctly for the Hyperlaunch name
>>     - communicating the value of it, differentiation for Xen
>>     - avoiding sub-branding it for feature subsets, use cases, technologies
>> 
>> - Retiring the term 'dom0less'
>> 
>> - How to describe the "starting multiple VMs at host boot" functionality
>> 
>>     - How to describe further Hyperlaunch functionality beyond this
>>         - eg. isolation properties and relevance to critical systems
>>         - eg. running without a classic dom0
>> 
>>     - How Hyperlaunch relates to other boot functionalities and technologies,
>>       including:
>>         - architecture-specific aspects and architecture-neutral aspects
>>         - Device Tree
>>         - boot domain
>>         - control domain, hardware domain, dom0
>>         - domain builder
>>         - system measurement
>>         - XSM
>>         - DRTM
>>         - etc.
>> 
>> 
>> = Migration
>> 
>> - Providing a forward path for existing users of dom0less functionality
>> across the technical changes for Hyperlaunch cross-architecture implementation
>>     - document compatibility
>>     - support a "dom0less mode" with existing Device Tree structure
>>     - documentation updates to be paired with progress on code implementation
>> 
>> 
>> = Community resourcing
>> 
>> - Supporting code review and merge of Hyperlaunch changes into Xen
>>     - transitioning existing Arm logic into common, including FDT
>> 
>> - Provision of accurate, consistent documentation materials to support
>> effective communication to existing and prospective users, developers and other
>> stakeholders
>>      - Ensuring that the document structure supports ongoing maintenance:
>>         - Multiple use cases, structure docs accordingly: eg.
>>             - use case: static partitioning, critical + non-critical VMs
>>             - use case: measured launch with a boot domain
>>             - use case: fast VM start for embedded systems
>>         - Architecture of Hyperlaunch, relevance to other hypervisors
>>             - nested systems
>> 
>> - Design, review and agreement for common cross-architecture and
>>   arch-extensible interfaces, including:
>>     - common boot data structures
>>     - Device Tree structure
>>     - hypfs entries
>>     - introspection to determine hyperlaunched system status
>> 
>> - Development of test cases
>> 
>> - CI of Hyperlaunch interfaces, to ensure that it stays working
>>  
>> ------------------------------------------------------------
>> 
>> Views arrived at in discussion with Rich and Daniel, and after reading the
>> thread contributions, follow this point.
>> 
>> "Hyperlaunch" is to be the common name across architectures for a flexible,
>> configurable boot system for coordinating the launch of multiple VMs by the
>> hypervisor, with a common implementation, pooling resources and development
>> risk across the Xen community. The interfaces are core to it.
>> 
>> From the Hyperlaunch design document (reviewed + committed to the tree):
>> 
>> "The design enables seamless transition for existing systems that require a dom0, and provides a new general capability to build and
>> launch alternative configurations of virtual machines, including support for static partitioning and accelerated start of VMs during
>> host boot, while adhering to the principles of least privilege. It incorporates the existing dom0less functionality, extended to fold
>> in the new developments from the Hyperlaunch project, with support for both x86 and Arm platform architectures, building upon and
>> replacing the earlier 'late hardware domain' feature for disaggregation of dom0.
>> 
>> Hyperlaunch is designed to be flexible and reusable across multiple use cases, and our aim is to ensure that it is capable, widely
>> exercised, comprehensively tested, and well understood by the Xen community."
>> 
>> https://xenbits.xen.org/docs/4.17-testing/designs/launch/hyperlaunch.html
>> 
>> ie.  Hyperlaunch was created to move away from point solutions that hard-code
>> specific launch configurations, isolation properties and threat models. It
>> isn't just about starting domains -- it is about enabling the construction of
>> complex use cases runtimes for Xen. It is the result of iterative design
>> starting with the disaggregation for the late hardware domain, through
>> dom0less development and then with the comprehensive hyperlaunch design and
>> implementation that builds upon them both.
>> 
>> The current interest and investment in Hyperlaunch is driven by its relevance
>> to Safety Critical systems due to the isolation properties and improvement
>> in the ability to certify the software -- this is closely related to but
>> slightly different from starting multiple VMs at host boot.
>> 
>> To encourage commonality and allow for future development, we should not
>> use architecture-specific or vendor-specific name variations, and also avoid
>> technology-specific name variations (eg. Device Tree or "DT").
>> 
>> Instead, the use case configurations should themselves be describable.
> 
> Thanks Christopher, Daniel and all!
> 
> So if I understand correctly, you are in favor if renaming Dom0less to
> Hyperlaunch throughout the Xen codebase? And we need a clarification of
> the docs/, especially docs/features/dom0less.pandoc?

Christopher wrote:
>> = Community resourcing

Note the pre-requisite work items for upstream Xen, listed under "Community Resourcing", to merge code for Hyperlaunch common interfaces and test cases, with docs on configuration of Hyperlaunch to deliver functionality for dom0less use cases.

Thanks,
Rich
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Luca Fancellu 9 months, 3 weeks ago 
>>> 
>>> Instead, the use case configurations should themselves be describable.
>> 
>> Thanks Christopher, Daniel and all!
>> 
>> So if I understand correctly, you are in favor if renaming Dom0less to
>> Hyperlaunch throughout the Xen codebase? And we need a clarification of
>> the docs/, especially docs/features/dom0less.pandoc?
> 
> Christopher wrote:
>>> = Community resourcing
> 
> Note the pre-requisite work items for upstream Xen, listed under "Community Resourcing", to merge code for Hyperlaunch common interfaces and test cases, with docs on configuration of Hyperlaunch to deliver functionality for dom0less use cases.

Are you saying that before renaming the “dom0less” feature, we should wait for it to be ported to the common code?

> 
> Thanks,
> Rich
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Rich Persaud 9 months, 3 weeks ago 
On Jul 8, 2023, at 03:29, Luca Fancellu <luca.fancellu@arm.com> wrote:
> 
>>>> 
>>>> Instead, the use case configurations should themselves be describable.
>>> 
>>> Thanks Christopher, Daniel and all!
>>> 
>>> So if I understand correctly, you are in favor if renaming Dom0less to
>>> Hyperlaunch throughout the Xen codebase? And we need a clarification of
>>> the docs/, especially docs/features/dom0less.pandoc?
>> 
>> Christopher wrote:
>>>> = Community resourcing
>> 
>> Note the pre-requisite work items for upstream Xen, listed under "Community Resourcing", to merge code for Hyperlaunch common interfaces and test cases, with docs on configuration of Hyperlaunch to deliver functionality for dom0less use cases.
> 
> Are you saying that before renaming the “dom0less” feature, we should wait for it to be ported to the common code?

Why "wait"? In what timeframe do you expect dom0less to use Hyperlaunch code?

Can kernel component foo adopt the name of kernel component bar without code change?

Can dom0less stakeholders derive Hyperlaunch benefits without using Hyperlaunch code?

Rich


P.S. An intellectual property story from Cambridge, UK
https://en.wikipedia.org/wiki/Leibniz–Newton_calculus_controversy
https://www.smithsonianmag.com/history/ten-famous-intellectual-property-disputes-18521880/

"By the early 18th century, many credited the German mathematician and philosopher Gottfried Wilhelm Leibniz with inventing the study of calculus. Leibniz had, after all, been the first to publish papers on the topic in 1684 and 1686. But when Englishman Isaac Newton published a book called Opticks in 1704, in which he asserted himself as the father of calculus, a debate arose. Each of the thinkers’ respective countries wanted to stake a claim in what was one of the biggest advances in mathematics."
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Stefano Stabellini 9 months, 3 weeks ago 
On Sat, 8 Jul 2023, Rich Persaud wrote:
> On Jul 8, 2023, at 03:29, Luca Fancellu <luca.fancellu@arm.com> wrote:
> > 
> >>>> 
> >>>> Instead, the use case configurations should themselves be describable.
> >>> 
> >>> Thanks Christopher, Daniel and all!
> >>> 
> >>> So if I understand correctly, you are in favor if renaming Dom0less to
> >>> Hyperlaunch throughout the Xen codebase? And we need a clarification of
> >>> the docs/, especially docs/features/dom0less.pandoc?
> >> 
> >> Christopher wrote:
> >>>> = Community resourcing
> >> 
> >> Note the pre-requisite work items for upstream Xen, listed under "Community Resourcing", to merge code for Hyperlaunch common interfaces and test cases, with docs on configuration of Hyperlaunch to deliver functionality for dom0less use cases.
> > 
> > Are you saying that before renaming the “dom0less” feature, we should wait for it to be ported to the common code?
> 
> Why "wait"? In what timeframe do you expect dom0less to use Hyperlaunch code?
> 
> Can kernel component foo adopt the name of kernel component bar without code change?
> 
> Can dom0less stakeholders derive Hyperlaunch benefits without using Hyperlaunch code?


I think Rich is saying that before using the same name we should make
sure that the interfaces and features are actually comparable and maybe
even "compatible". I think that is very reasonable. Rich, did I
understand correctly?


The Hyperlaunch (x86) code is not yet upstream, but the design document
that describes the device tree interface shows an interface that is very
similar, almost compatible, with today's dom0less (ARM) device tree
interface.

The structure of the device tree information is the same. Going through
it I could only spot only tiny differences:
- top level node is "hypervisor" instead of "chosen"
- "module-addr" instead of "reg"
- "module,kernel" instead of "multiboot,kernel"
- "module,ramdisk" instead of "multiboot,ramdisk" 

The rest is the same. If we sort out these small differences one way or
the other then the resulting interface should actually be fully
compatible and we could reuse the existing Dom0less (ARM) code to parse
an HyperLaunch (x86) configuration.

The top level node is not a problem. We could easily deal with both
"hypervisor" and also "chosen". Or we could pick a third different name
for both: "domains" which is the one used by System Device Tree.

I think we should rename "module-addr" to "reg" in the hyperlaunch
design document. I don't think it would have any effect on the existing
hyperlaunch (x86) code and usage because direct addresses are typically
not used on x86.

"module,kernel" and "module,ramdisk": we could either get rid of them in
favor of "multiboot,kernel" and "multiboot,ramdisk", or we could add
"module,kernel" and "module,ramdisk" as alternative aliases in the
existing dom0less (ARM) code. We already have "xen,linux-zimage" and
"xen,linux-initrd" as aliases so it is not a problem.


Also, I do think that Dom0less stakeholders would benefit from
Hyperlaunch code such as Dom0's reduction of privilege. Things like
"permissions" and "functions" of the Hyperlauch device tree interface
design document.


So, my opinion is that we should go ahead with dom0less->hyperlaunch
rename but we should also try to make the two device tree interfaces
compatible, sorting out the small differences above. That would help a
lot in terms of documentation and tooling. It would be ideal if things
like ImageBuilder worked equally well for Hyperlaunch (x86) and Dom0less
(ARM).


P.S.
Note that I only added (ARM) and (x86) for extra clarity in this
discussion, and I don't want to keep using them going forward.
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Daniel P. Smith 9 months, 3 weeks ago 
On 7/8/23 14:08, Stefano Stabellini wrote:
 > On Sat, 8 Jul 2023, Rich Persaud wrote:
 >> On Jul 8, 2023, at 03:29, Luca Fancellu <luca.fancellu@arm.com> wrote:
 >>> 
 >>>>>>
 >>>>>> Instead, the use case configurations should themselves be 
describable.
 >>>>>
 >>>>> Thanks Christopher, Daniel and all!
 >>>>>
 >>>>> So if I understand correctly, you are in favor if renaming 
Dom0less to
 >>>>> Hyperlaunch throughout the Xen codebase? And we need a 
clarification of
 >>>>> the docs/, especially docs/features/dom0less.pandoc?
 >>>>
 >>>> Christopher wrote:
 >>>>>> = Community resourcing
 >>>>
 >>>> Note the pre-requisite work items for upstream Xen, listed under 
"Community Resourcing", to merge code for Hyperlaunch common interfaces 
and test cases, with docs on configuration of Hyperlaunch to deliver 
functionality for dom0less use cases.
 >>>
 >>> Are you saying that before renaming the “dom0less” feature, we 
should wait for it to be ported to the common code?
 >>
 >> Why "wait"? In what timeframe do you expect dom0less to use 
Hyperlaunch code?
 >>
 >> Can kernel component foo adopt the name of kernel component bar 
without code change?
 >>
 >> Can dom0less stakeholders derive Hyperlaunch benefits without using 
Hyperlaunch code?
 >
 >
 > I think Rich is saying that before using the same name we should make
 > sure that the interfaces and features are actually comparable and maybe
 > even "compatible". I think that is very reasonable. Rich, did I
 > understand correctly?

Essentially, yes this is what is being sought here. This does not mean 
that the full capability has to be present for the adoption of the 
common name, but that it can be accomplished through a path of integration.

 > The Hyperlaunch (x86) code is not yet upstream, but the design document
 > that describes the device tree interface shows an interface that is very
 > similar, almost compatible, with today's dom0less (ARM) device tree
 > interface.

I would caution the use of the current in-tree document as it is today, 
it was posted under the design folder as it was only the design and not 
burdened with the realities of implementation. Along the path of v1 
implementation, recent PVH expansion, and roles update, each have 
required updates to the design which are not yet included in the in-tree 
docs.

To address, this the plan below starts with the documentation patch 
posted in v1 of the hyperlaunch series:

 
https://lists.xenproject.org/archives/html/xen-devel/2022-07/msg00353.html

and will contain updates for community feedback received:

 
https://lists.xenproject.org/archives/html/xen-devel/2022-07/msg01015.html

and development work that has been done for PVH and roles.

 > The structure of the device tree information is the same. Going through
 > it I could only spot only tiny differences:
 > - top level node is "hypervisor" instead of "chosen"
 > - "module-addr" instead of "reg"
 > - "module,kernel" instead of "multiboot,kernel"
 > - "module,ramdisk" instead of "multiboot,ramdisk"
 >
 > The rest is the same. If we sort out these small differences one way or
 > the other then the resulting interface should actually be fully
 > compatible and we could reuse the existing Dom0less (ARM) code to parse
 > an HyperLaunch (x86) configuration.
 >
 > The top level node is not a problem. We could easily deal with both
 > "hypervisor" and also "chosen". Or we could pick a third different name
 > for both: "domains" which is the one used by System Device Tree.
 >
 > I think we should rename "module-addr" to "reg" in the hyperlaunch
 > design document. I don't think it would have any effect on the existing
 > hyperlaunch (x86) code and usage because direct addresses are typically
 > not used on x86.
 >
 > "module,kernel" and "module,ramdisk": we could either get rid of them in
 > favor of "multiboot,kernel" and "multiboot,ramdisk", or we could add
 > "module,kernel" and "module,ramdisk" as alternative aliases in the
 > existing dom0less (ARM) code. We already have "xen,linux-zimage" and
 > "xen,linux-initrd" as aliases so it is not a problem.
 >
 >
 > Also, I do think that Dom0less stakeholders would benefit from
 > Hyperlaunch code such as Dom0's reduction of privilege. Things like
 > "permissions" and "functions" of the Hyperlauch device tree interface
 > design document.

The roles work takes that to its final conclusion, from which everyone 
will benefit.

 > So, my opinion is that we should go ahead with dom0less->hyperlaunch
 > rename but we should also try to make the two device tree interfaces
 > compatible, sorting out the small differences above. That would help a
 > lot in terms of documentation and tooling. It would be ideal if things
 > like ImageBuilder worked equally well for Hyperlaunch (x86) and Dom0less
 > (ARM).

Let me build on the plan laid out by Christopher, that detailed arriving 
at the completion for hyperlaunch, and provide a set of steps to arrive 
at a new short-term milestone to a larger roadmap. The intent being to 
arrive at the immediate desire of the community to see dom0less renamed. 
For the longer term, as Christopher was alluding, there is still a 
significant amount of work to be done to deliver one of the biggest 
market differentiating capabilities for Xen in some time.

As Stefano has acknowledged, hyperlaunch is a concept that is beyond 
domain construction and that is, or will be, embodied by a set of 
interfaces and capabilities. Considering dom0less as it is implemented 
today, does not meet the former and in spirit meets the latter. 
Compounding this is that dom0less is a supported feature today, with its 
own defined interface, and a user base that is using that interface, at 
least to some degree AIUI.

We have a responsibility to the dom0less user base and future 
hyperlaunch users with requirements based on hyperlaunch design docs and 
presentations.  As such, any action taken should be done so under a 
larger roadmap of adding the complete hyperlaunch capability to Xen.

With the initial funding by AMD, the first milestone was to be moving 
Xen on to a common representation of boot material provided to the 
hypervisor. As a result of this discussion, I would like to put forth a 
new nearer term milestone of incorporating dom0less under hyperlaunch.

The naming suggestions by the community are greatly appreciated, and I 
do not want to seem dismissive of clear offers of help and assistance. 
This area is something Christopher and I discussed at length during the 
drafting of the hyperlaunch design. Something we arrived at is that 
there is only a single top level feature, which is hyperlaunch. The 
hyperlaunch feature itself will provide multiple means to configure how 
a launch will occur, one could even consider them modes of operation.

Reviewing the design doc, you will see that an initial attempt to 
categorize them was done, splitting them into a dynamic mode and static 
mode. Under these modes were multiple use cases. With that, we did not 
mean to limit the hyperlaunch modes to strictly those two, and thus 
other modes are more than reasonable to add. As such, my suggestion 
would be the introduction of the dom0less compatibility mode for 
hyperlaunch. Its very definition is a mode of hyperlaunch that supports 
the "legacy" dom0less configuration interface. This approach allows 
dom0less to effectively become hyperlaunch, deconflicts the fact that 
hyperlaunch proper has a different interface than dom0less, and provides 
a clean roadmap for migration to existing dom0less users.

To provide a concrete, measurable set of steps to achieve the dom0less 
merging milestone, I will lay out the approach as three patch series 
that will be a collaboration by the community. Each will need to be 
submitted, reviewed and merged into the tree, with the end being the 
existing dom0less becoming hyperlaunch's dom0less compatibility mode.

== Patch Series 1 (Resourced by Apertus)

The goal of this series is to properly introduce the hyperlaunch 
"feature" in to Xen. This series would be submitted by myself and will 
consist of two patches derived from the original hyperlaunch v1 series. 
The first patch is the docs patch that updates the hyperlaunch device 
tree design to reflect review feedback and updates for PVH and roles, 
mentioned above.

The second patch will start with the v1 series patch that moved the fdt 
parsing helpers into common:
https://lists.xenproject.org/archives/html/xen-devel/2022-07/msg00352.html

The patch currently moves common FDT parsing to common/fdt.c, it will be 
updated to add this path to DEVICE TREE in MAINTAINERS. As part of 
updating MAINTAINERS, there will be the addition of HYPERLAUNCH, which 
will own common/domain-builder/ and doc/design/launch paths. As such, 
this will effectively be a declaration of the top level hyperlaunch 
feature, with this as an interface, and establish the maintainers of the 
feature.

== Patch Series 2 (Requesting resourcing by Arm)

The goal of this series would be to move the dom0less device tree 
parsing under hyperlaunch. We would respectfully request a member of the 
Arm community to volunteer to take ownership and steward the series 
through submission and review process.

The implementation of this series would see dom0less device tree parsing 
to use, and expand if necessary, the common/fdt parsing helpers. I 
personally would see this logic move under common/domain-builder using a 
file name that would not collide with the files from the hyperlaunch v1 
series, e.g.  a suggestion would be fdt-dom0less.c.

As for ownership of that file, I would suggest the addition of a 
HYPERLAUNCH DOM0LESS COMPATIBILITY be added to MAINTAINERS with the 
appropriate Arm community members, but understand and willing to 
consider the position that it falls under HYPERLAUNCH. The purpose of 
using HYPERLAUNCH DOM0LESS COMPATIBILITY will be to provide a means to 
signal the retirement of dom0less compatibility mode at some future point.

== Patch Series 3 (Resourced by Apertus)

The goal of this series will be to formalize hyperlaunch dom0less 
compatibility mode. The series would be submitted by myself and/or 
Christopher. It will consist of documentation patches that will add a 
doc/features/hyperlaunch.rst and a 
doc/features/hyperlaunch/dom0less-compatiblilty.rst. The hyperlaunch.rst 
path will fall under HYPERLAUNCH, while dom0less-compatiblilty.rst will 
fall under HYPERLAUNCH DOM0LESS COMPATIBILITY. This will also see 
DOM0LESS in SUPPORTED.md be renamed to HYPERLAUNCH.

In summary, I would like to reiterate points made by Rich and 
Christopher. The motivation and concept of the hypervisor 
differentiating capability that is hyperlaunch goes back to the 2012 
domain builder work that was a companion to the hardware domain work.

Since then, there have been a few of us in the OpenXT community that 
desired to make this an integral part of Xen. Internal OpenXT 
discussions in 2017-2018 along with the announcement of dom0less 
inspired confidence there were in fact other uses cases and interest in 
Xen gaining such an integrated capability.

A fact that should not go overlooked or undervalued is that hyperlauch 
would not exist today without the extremely generous support StarLab 
provided to sponsor Christopher and I to do the R&D, proof of viability, 
and a full working prototype that provided the basis for the v1 series. 
This was not a minor investment on their part, and taking the design to 
completion requires further substantial investment. Due to an 
acquisition imposed shift in market focus, StarLab has since stepped away.

Fortunately, and for which we are immensely appreciative, AMD has 
recently stepped up to fund some hyperlaunch work items. With a growing 
number of hyperlaunch use cases, I would be happy to help those with 
budgetary influence to communicate the business benefits of investment 
in open work items, targeting specific launch configurations, safety and 
security properties.

The amount of work to be done goes beyond just parallel domain 
construction, there are tangential capabilities that need updating and 
incorporation. For instance, a topic discussed during the summit, VPCI 
and device assignment at/during hypervisor startup. Anyone looking or 
willing to provide purely financial support, feel free to reach out 
directly to Christopher and me, as we have a few avenues to enable the 
flow of funds.

Attached are candidate work items for funding and resourcing of 
hyperlaunch integration, building upon the proposed Apertus and Arm 
patch series for dom0less rename and migration to hyperlaunch common 
interfaces.

Lastly, thank you to everyone who has taken the time to engage and 
collaborate on how to resolve the task at hand!

V/r,
Daniel P. Smith

===

Here are outlines for the next development items appropriate for funding 
for progress on hyperlaunch integration, following on from the three 
series described above.

== Work Item: initial x86 Hyperlaunch SUPPORT and launch of dom0 
(Resourcing TBD)

The goal is to enable initial hyperlaunch SUPPORT on x86, building upon 
from the work in the posted v3 series of hyperlaunch.

Development proceeds from patches 9-12 of the v1 hyperlaunch series, to 
add boot with minimal construction of a classic dom0 from a device tree 
configuration. The Hyperlaunch SUPPORT statement would add x86 and Xen 
nightly CI and release-gating test configurations would be extended to 
include hyperlaunch on x86.


== Work Item: Hyperlaunch XSM policy for guests (Resourcing TBD)

The goal is to ensure that security policies of guests started via 
hyperlaunch are accurately aligned with the configured functions of each 
guest, which would allow for reduction of privilege of the dom0 in 
dom0less systems.

A new XSM policy with granular permissions for domain functions, aligned 
with the roles work, would be integrated into the hypervisor.  It would 
define new domain security labels appropriate for assigning to domUs, 
matching privileges for the domain functions that can be assigned with 
hyperlaunch, and allowing for more expressive policy control than is 
expressible with dom0less.


== Work Item: Hyperlaunch of Arm guests SUPPORT (Resourcing TBD)

The goal of this effort is to enable hyperlaunch of Arm guests.

It would enable use of the architecture-common Hyperlaunch Device Tree 
format on Arm, providing the forward migration path from the Dom0less 
format, to the new format with additional flexibility for guest 
construction, including control over console privilege assignment and 
XSM label control.

It would achieve the objective of using common cross-architecture boot 
structures and community-maintained common code.

Development would proceed from patches 9-10 of the v1 hyperlaunch 
series, to add boot with construction of dom0 and domU guests from a 
hyperlaunch device tree configuration.

Xen nightly CI and release-gating test configurations would be extended 
to include hyperlaunch with guests on Arm.


== Work Item: Hyperlaunch of x86 PV and PVH guests (Resourcing TBD)

The goal of this effort is to enable Hyperlaunch of x86 PV and PVH guests.

This builds upon the initial x86 Hyperlaunch support to add domain 
construction of PV and PVH guests.

Xen nightly CI and release-gating test configurations would be extended 
to include hyperlaunch with guests on x86.


== Work Item: XSM-enforced FuSA (Resourcing TBD)

Hyperlaunch enables disaggregation, and XSM enables granular policy.

The goal of this work is to design and implement new modular, 
fine-grained policy to integrate into Xen for control for 
safety-critical VMs and isolation from non-safety-critical VMs.


== Work Item: Design for Hyperlaunch of x86 HVM guests (Resourcing TBD)

The goal of this effort is to research, prototype and produce design 
documentation for enabling hyperlaunch of x86 HVM guests, ie. with 
support for a device emulator.

This would build upon the x86 Hyperlaunch support for PVH guests.

Investigation to consider:
- launch alongside a classic dom0 domain
- launch on a static partitioned system without a dom0
- stub domains for device emulator isolation
- boot domain integration
- device assignment


-- Thanks for your consideration!
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Luca Fancellu 9 months, 3 weeks ago 

> On 6 Jul 2023, at 11:01, George Dunlap <george.dunlap@cloud.com> wrote:
> 
> 
> 
> On Wed, Jul 5, 2023 at 11:14 PM Stefano Stabellini <stefano.stabellini@amd.com> wrote:
> On Wed, 5 Jul 2023, George Dunlap wrote:
> > On Mon, Jul 3, 2023 at 9:55 PM P S <pairspace@gmail.com> wrote:
> >       > On Jul 3, 2023, at 15:45, Luca Fancellu <luca.fancellu@arm.com> wrote:
> >       >
> >       >> On 3 Jul 2023, at 18:48, Stefano Stabellini <sstabellini@kernel.org> wrote:
> >       >>
> >       >>> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
> >       >>> On 7/1/23 11:13, Luca Fancellu wrote:
> >       >>>>> On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >       >>>>>
> >       >>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
> >       >>>>>> The "dom0less" feature was intended to be the feature where a domU
> >       >>>>>> domain could be launched without the control domain (Dom0)
> >       >>>>>> intervention, however the name seems to suggest that Dom0 cannot
> >       >>>>>> be part of the configuration, while instead it's a possible use case.
> >       >>>>>>
> >       >>>>>> To avoid that, rename the "dom0less" configuration with the name
> >       >>>>>> "hyperlaunch", that is less misleading.
> >       >>>>>>
> >       >>>>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
> >       >>>>>> ---
> >       >>>>>> This is an RFC to get the feeling of the community about the name
> >       >>>>>> change, for now it's everything in one patch just to see how it
> >       >>>>>> will look like, if there is interest on proceeding into it, I can
> >       >>>>>> split in more commit.
> >       >>>>>
> >       >>>>> Have you discussed this with Dan and Chris at all?  You haven't even
> >       >>>>> CC'd them.
> >       >>>>
> >       >>>> No, this rename idea started from a chat during the summit, anyway Julien
> >       >>>> promptly add them to the CC, because I forgot.
> >       >>>
> >       >>> No worries and thank you for considering and taking the time to do this RFC.
> >       >>> It is greatly appreciated that there is a strong willingness to have dom0less
> >       >>> and hyperlaunch merged.
> >       >>>
> >       >>>>>
> >       >>>>> While there is a lot of end-goal in common between the dom0less and
> >       >>>>> hyperlaunch, and that the name dom0less is deeply misleading,
> >       >>>>> hyperlaunch is specifically not this.
> >       >>>>
> >       >>>> Yes Hyperlaunch is more than this, however as I said, with this RFC I would
> >       >>>> like
> >       >>>> to ear opinions, @Daniel @Christopher could it be a proper name for the
> >       >>>> dom0less
> >       >>>> feature?
> >       >>>
> >       >>> As Andy has alluded, hyperlaunch is meant to provide a flexible means to
> >       >>> handle domain construction at boot to meet a wide range of possible use cases.
> >       >>> One of those use cases is dom0less, so yes, ultimately what dom0less does
> >       >>> today will be achievable under hyperlaunch. Our intended approach to align the
> >       >>> two implementations is one that is meant to be minimally disruptive, since
> >       >>> dom0less is considered a supported (SUPPORT.md) capability. As mentioned, we
> >       >>> are greatly appreciative to the openness to adopt the name,
> >       >>
> >       >> Thanks Daniel!
> >       >>
> >       >>
> >       >>> but a big concern
> >       >>> I personally have is the confusion it could cause a general user. A blanket
> >       >>> rename would end up with two documents in the docs tree that provide two
> >       >>> different explanations of hyperlaunch and two different device tree
> >       >>> definitions. So I think a more measured approach should be considered here.
> >       >>>
> >       >>>> If this patch makes things more difficult for the Hyperlunch serie, I’m ok
> >       >>>> to drop it,
> >       >>>> my only aim was just to find a less misleading name for the feature.
> >       >>>
> >       >>> What I would like to suggest as a good first step would be an update to the
> >       >>> dom0less document. Provide a note at the beginning that points to the
> >       >>> hyperlaunch design doc as a more general approach that will eventually subsume
> >       >>> dom0less. This would provide a gentler transition for exist users of dom0less.
> >       >>>
> >       >>> If it is not too much, I would also ask, please have a look at the design for
> >       >>> boot modules in the series Christopher just posted. The design pulls from the
> >       >>> work done by dom0less and expanded upon it. I major step into merging the two
> >       >>> capabilities will be to have a common set of structures. Once those are in
> >       >>> place, we can move to a common device tree representation, and at that point
> >       >>> we would be fairly close, if not at the point of a formal merger of between
> >       >>> the two.
> >       >>
> >       >> At the moment we have a concrete problem with explaining dom0less and
> >       >> hyperlaunch to potential new users. Using two different names for a
> >       >> similar feature on arm and x86 causes confusion. It is hurting Xen as a
> >       >> solution. Personally I already had to switch to use the word
> >       >> "hyperlaunch" for everything in my users-facing presentations.
> >       >>
> >       >> At the summit, we discussed that it would be a good idea to use a single
> >       >> name to refer to both features on arm and x86. Given that "dom0less"
> >       >> causes additional issues because it makes people think that there is no
> >       >> Dom0, the suggestion was to use "hyperlaunch" to refer to both features.
> >       >>
> >       >> We don't need to 100% align the two implementations and data structures.
> >       >> This is not for engineers that are going to look at the specifications
> >       >> and improve them. This is for users/customers of Xen that are trying to
> >       >> understand what the hypervisor enables them to do. We need to be able to
> >       >> show users architecture slides with the same name and explanation on
> >       >> both ARM and x86.
> >       >>
> >       >> I am sure that Daniel and Christopher remember, but for the others on
> >       >> this email thread, the name "hyperlaunch" was born exactly to be that:
> >       >> the one name to cover both features on ARM and x86 even if they have a
> >       >> different implementation. Appended an old email for reference.
> >       >>
> >       >> Also I agree with Daniel that we need to be careful about the two docs
> >       >> under docs/. I think he is right we need to add a paragraph explaining
> >       >> the history and a pointer to the other document. Something like:
> >       >>
> >       >> "Dom0less is the name that was used when initially introducing the
> >       >> feature on ARM. Then, the "dom0less" name was retired in favor of
> >       >> "hyperlaunch" to avoid confusion (a Dom0 might still be present) and to
> >       >> align with x86 (where a similar feature was called hyperlaunch from the
> >       >> start)."
> >       >
> >       > I’m fully ok to add a section like this pointing to the Hyperlaunch design.
> > 
> >       _If_ this text is added, please include links/references to the Hyperlaunch wiki page and Hyperlaunch design docs.
> > 
> >       > @Daniel and @Christopher would it be ok for you or the changes in the serie
> >       > are going to be problematic for your future work? In the end it’s just a mechanical
> >       > rename, so I guess we just need to agree on naming conventions.
> > 
> >       Please see the history of trademark litigation about the use of symbolic names to reference similar-but-different artifacts. 
> >       It is much easier to use the same name to refer to entirely different objects. Historically, confusion arises when a name is
> >       used in similar contexts.
> > 
> >       There is also versioning.  Could we refer to dom0less as "Hyperlaunch Version -1"?
> > 
> >       How about renaming dom0less to "Hyperlaunch Lite"?
> > 
> > 
> > Perhaps it would be helpful if you could explain more clearly your concerns.  I take it that you want a name which can be used specifically
> > to indicate the full "domB measured boot" functionality that was Daniel and Christopher's original goal, and that you're afraid that using
> > plain "Hyperlaunch" for only the "start VMs from Xen on boot" functionality will dilute that?
> > 
> > The "start VMs from Xen on boot" functionality is the *only* thing that a big chunk of the users of this functionality want;  referring to
> > it as "Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the value of the functionality.
> > 
> > What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured Boot" to refer to the full measured boot functionality?
> 
> I think this is the best way.
> 
> 
> > Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device Tree" (without the involvement of a domB), "Hyperlaunch Boot Domain /
> > Hyperlaunch domB" for a more general "domB" functionality, and "Hyperlaunch Measured Boot" for the full functionality (assuming there's
> > more to this than simply having a domB involved)?
> 
> 
> We need an overarching name to cover the feature "start VMs from Xen on
> boot" on both ARM and x86. From my understanding and from the original
> emails on the subject, the name "hyperlaunch" was it.
> 
> Sure; but think "guitar" vs "acoustic guitar" vs "electric guitar".  "Electric guitar" is new, "guitar" covers them both, but you sometimes need a way to specify "acoustic".  Right now target configurations we're talking about include:
> 
> 1. Booting all your domains directly from Xen using DT configurations
> 2. Booting a domB, which then executes some more complicated programmatic configuration to launch VMs before disappearing
> 3. Doing full measured boot on the whole system using a domB.
> 
> If "Hyperlaunch" means 1-3, we not only need a way to specify that you're talking about 3, but *also* a way to specify that you're talking about 1.  In the vast majority of cases for the foreseeable future are going to be 1.  Additionally, we want to make sure that "Hyperlaunch" *actually* turns out to mean 1-3, and not just 1.
> 
> The thing I like about "Hyperlaunch DT" is that to me it sounds pretty cool but also is very descriptive: I haven't talked to people building these systems, but it seems like saying, "The hypervisor launches VMs based on a Device Tree passed to it at boot" will be immediately understood, and stick in people's minds.

Personally, I like the name “Hyperlaunch DT”, because it tells me that we are launching VMs and the DT is involved, if I understood correctly the design,
it would be the same also on x86 (and in every architecture that will come later) so being “Hyperlaunch DT” an arch agnostic name makes it a good
candidate for phase out dom0less name and for the future when a common code will use the DT to launch VMs at Xen boot.


> 
> So maybe informally, or in "short usage" use "Hyperlaunch", but in documentation or reference systems, when talking specifically about #1, try to use "Hyperlaunch DT", just to reinforce the idea that there's more to Hyperlaunch that's coming down the road?
> 
>  -George
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Julien Grall 9 months, 3 weeks ago 

On 06/07/2023 13:31, Luca Fancellu wrote:
> 
> 
>> On 6 Jul 2023, at 11:01, George Dunlap <george.dunlap@cloud.com> wrote:
>>
>>
>>
>> On Wed, Jul 5, 2023 at 11:14 PM Stefano Stabellini <stefano.stabellini@amd.com> wrote:
>> On Wed, 5 Jul 2023, George Dunlap wrote:
>>> On Mon, Jul 3, 2023 at 9:55 PM P S <pairspace@gmail.com> wrote:
>>>        > On Jul 3, 2023, at 15:45, Luca Fancellu <luca.fancellu@arm.com> wrote:
>>>        >
>>>        >> On 3 Jul 2023, at 18:48, Stefano Stabellini <sstabellini@kernel.org> wrote:
>>>        >>
>>>        >>> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
>>>        >>> On 7/1/23 11:13, Luca Fancellu wrote:
>>>        >>>>> On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>        >>>>>
>>>        >>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
>>>        >>>>>> The "dom0less" feature was intended to be the feature where a domU
>>>        >>>>>> domain could be launched without the control domain (Dom0)
>>>        >>>>>> intervention, however the name seems to suggest that Dom0 cannot
>>>        >>>>>> be part of the configuration, while instead it's a possible use case.
>>>        >>>>>>
>>>        >>>>>> To avoid that, rename the "dom0less" configuration with the name
>>>        >>>>>> "hyperlaunch", that is less misleading.
>>>        >>>>>>
>>>        >>>>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
>>>        >>>>>> ---
>>>        >>>>>> This is an RFC to get the feeling of the community about the name
>>>        >>>>>> change, for now it's everything in one patch just to see how it
>>>        >>>>>> will look like, if there is interest on proceeding into it, I can
>>>        >>>>>> split in more commit.
>>>        >>>>>
>>>        >>>>> Have you discussed this with Dan and Chris at all?  You haven't even
>>>        >>>>> CC'd them.
>>>        >>>>
>>>        >>>> No, this rename idea started from a chat during the summit, anyway Julien
>>>        >>>> promptly add them to the CC, because I forgot.
>>>        >>>
>>>        >>> No worries and thank you for considering and taking the time to do this RFC.
>>>        >>> It is greatly appreciated that there is a strong willingness to have dom0less
>>>        >>> and hyperlaunch merged.
>>>        >>>
>>>        >>>>>
>>>        >>>>> While there is a lot of end-goal in common between the dom0less and
>>>        >>>>> hyperlaunch, and that the name dom0less is deeply misleading,
>>>        >>>>> hyperlaunch is specifically not this.
>>>        >>>>
>>>        >>>> Yes Hyperlaunch is more than this, however as I said, with this RFC I would
>>>        >>>> like
>>>        >>>> to ear opinions, @Daniel @Christopher could it be a proper name for the
>>>        >>>> dom0less
>>>        >>>> feature?
>>>        >>>
>>>        >>> As Andy has alluded, hyperlaunch is meant to provide a flexible means to
>>>        >>> handle domain construction at boot to meet a wide range of possible use cases.
>>>        >>> One of those use cases is dom0less, so yes, ultimately what dom0less does
>>>        >>> today will be achievable under hyperlaunch. Our intended approach to align the
>>>        >>> two implementations is one that is meant to be minimally disruptive, since
>>>        >>> dom0less is considered a supported (SUPPORT.md) capability. As mentioned, we
>>>        >>> are greatly appreciative to the openness to adopt the name,
>>>        >>
>>>        >> Thanks Daniel!
>>>        >>
>>>        >>
>>>        >>> but a big concern
>>>        >>> I personally have is the confusion it could cause a general user. A blanket
>>>        >>> rename would end up with two documents in the docs tree that provide two
>>>        >>> different explanations of hyperlaunch and two different device tree
>>>        >>> definitions. So I think a more measured approach should be considered here.
>>>        >>>
>>>        >>>> If this patch makes things more difficult for the Hyperlunch serie, I’m ok
>>>        >>>> to drop it,
>>>        >>>> my only aim was just to find a less misleading name for the feature.
>>>        >>>
>>>        >>> What I would like to suggest as a good first step would be an update to the
>>>        >>> dom0less document. Provide a note at the beginning that points to the
>>>        >>> hyperlaunch design doc as a more general approach that will eventually subsume
>>>        >>> dom0less. This would provide a gentler transition for exist users of dom0less.
>>>        >>>
>>>        >>> If it is not too much, I would also ask, please have a look at the design for
>>>        >>> boot modules in the series Christopher just posted. The design pulls from the
>>>        >>> work done by dom0less and expanded upon it. I major step into merging the two
>>>        >>> capabilities will be to have a common set of structures. Once those are in
>>>        >>> place, we can move to a common device tree representation, and at that point
>>>        >>> we would be fairly close, if not at the point of a formal merger of between
>>>        >>> the two.
>>>        >>
>>>        >> At the moment we have a concrete problem with explaining dom0less and
>>>        >> hyperlaunch to potential new users. Using two different names for a
>>>        >> similar feature on arm and x86 causes confusion. It is hurting Xen as a
>>>        >> solution. Personally I already had to switch to use the word
>>>        >> "hyperlaunch" for everything in my users-facing presentations.
>>>        >>
>>>        >> At the summit, we discussed that it would be a good idea to use a single
>>>        >> name to refer to both features on arm and x86. Given that "dom0less"
>>>        >> causes additional issues because it makes people think that there is no
>>>        >> Dom0, the suggestion was to use "hyperlaunch" to refer to both features.
>>>        >>
>>>        >> We don't need to 100% align the two implementations and data structures.
>>>        >> This is not for engineers that are going to look at the specifications
>>>        >> and improve them. This is for users/customers of Xen that are trying to
>>>        >> understand what the hypervisor enables them to do. We need to be able to
>>>        >> show users architecture slides with the same name and explanation on
>>>        >> both ARM and x86.
>>>        >>
>>>        >> I am sure that Daniel and Christopher remember, but for the others on
>>>        >> this email thread, the name "hyperlaunch" was born exactly to be that:
>>>        >> the one name to cover both features on ARM and x86 even if they have a
>>>        >> different implementation. Appended an old email for reference.
>>>        >>
>>>        >> Also I agree with Daniel that we need to be careful about the two docs
>>>        >> under docs/. I think he is right we need to add a paragraph explaining
>>>        >> the history and a pointer to the other document. Something like:
>>>        >>
>>>        >> "Dom0less is the name that was used when initially introducing the
>>>        >> feature on ARM. Then, the "dom0less" name was retired in favor of
>>>        >> "hyperlaunch" to avoid confusion (a Dom0 might still be present) and to
>>>        >> align with x86 (where a similar feature was called hyperlaunch from the
>>>        >> start)."
>>>        >
>>>        > I’m fully ok to add a section like this pointing to the Hyperlaunch design.
>>>
>>>        _If_ this text is added, please include links/references to the Hyperlaunch wiki page and Hyperlaunch design docs.
>>>
>>>        > @Daniel and @Christopher would it be ok for you or the changes in the serie
>>>        > are going to be problematic for your future work? In the end it’s just a mechanical
>>>        > rename, so I guess we just need to agree on naming conventions.
>>>
>>>        Please see the history of trademark litigation about the use of symbolic names to reference similar-but-different artifacts.
>>>        It is much easier to use the same name to refer to entirely different objects. Historically, confusion arises when a name is
>>>        used in similar contexts.
>>>
>>>        There is also versioning.  Could we refer to dom0less as "Hyperlaunch Version -1"?
>>>
>>>        How about renaming dom0less to "Hyperlaunch Lite"?
>>>
>>>
>>> Perhaps it would be helpful if you could explain more clearly your concerns.  I take it that you want a name which can be used specifically
>>> to indicate the full "domB measured boot" functionality that was Daniel and Christopher's original goal, and that you're afraid that using
>>> plain "Hyperlaunch" for only the "start VMs from Xen on boot" functionality will dilute that?
>>>
>>> The "start VMs from Xen on boot" functionality is the *only* thing that a big chunk of the users of this functionality want;  referring to
>>> it as "Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the value of the functionality.
>>>
>>> What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured Boot" to refer to the full measured boot functionality?
>>
>> I think this is the best way.
>>
>>
>>> Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device Tree" (without the involvement of a domB), "Hyperlaunch Boot Domain /
>>> Hyperlaunch domB" for a more general "domB" functionality, and "Hyperlaunch Measured Boot" for the full functionality (assuming there's
>>> more to this than simply having a domB involved)?
>>
>>
>> We need an overarching name to cover the feature "start VMs from Xen on
>> boot" on both ARM and x86. From my understanding and from the original
>> emails on the subject, the name "hyperlaunch" was it.
>>
>> Sure; but think "guitar" vs "acoustic guitar" vs "electric guitar".  "Electric guitar" is new, "guitar" covers them both, but you sometimes need a way to specify "acoustic".  Right now target configurations we're talking about include:
>>
>> 1. Booting all your domains directly from Xen using DT configurations
>> 2. Booting a domB, which then executes some more complicated programmatic configuration to launch VMs before disappearing
>> 3. Doing full measured boot on the whole system using a domB.
>>
>> If "Hyperlaunch" means 1-3, we not only need a way to specify that you're talking about 3, but *also* a way to specify that you're talking about 1.  In the vast majority of cases for the foreseeable future are going to be 1.  Additionally, we want to make sure that "Hyperlaunch" *actually* turns out to mean 1-3, and not just 1.
>>
>> The thing I like about "Hyperlaunch DT" is that to me it sounds pretty cool but also is very descriptive: I haven't talked to people building these systems, but it seems like saying, "The hypervisor launches VMs based on a Device Tree passed to it at boot" will be immediately understood, and stick in people's minds.
> 
> Personally, I like the name “Hyperlaunch DT”, because it tells me that we are launching VMs and the DT is involved, if I understood correctly the design,
> it would be the same also on x86 (and in every architecture that will come later) so being “Hyperlaunch DT” an arch agnostic name makes it a good
> candidate for phase out dom0less name and for the future when a common code will use the DT to launch VMs at Xen boot.

I assume that DT means Device-Tree here. If so, I find a name a bit 
misleading because we are talking about the way to pass the 
configuration rather than what the feature is doing.

My assumption here is that a DomB solution would still use the 
Device-Tree to describe the domains.

Cheers,

-- 
Julien Grall
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Luca Fancellu 9 months, 3 weeks ago 
>>>> 
>>>> The "start VMs from Xen on boot" functionality is the *only* thing that a big chunk of the users of this functionality want;  referring to
>>>> it as "Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the value of the functionality.
>>>> 
>>>> What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured Boot" to refer to the full measured boot functionality?
>>> 
>>> I think this is the best way.
>>> 
>>> 
>>>> Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device Tree" (without the involvement of a domB), "Hyperlaunch Boot Domain /
>>>> Hyperlaunch domB" for a more general "domB" functionality, and "Hyperlaunch Measured Boot" for the full functionality (assuming there's
>>>> more to this than simply having a domB involved)?
>>> 
>>> 
>>> We need an overarching name to cover the feature "start VMs from Xen on
>>> boot" on both ARM and x86. From my understanding and from the original
>>> emails on the subject, the name "hyperlaunch" was it.
>>> 
>>> Sure; but think "guitar" vs "acoustic guitar" vs "electric guitar".  "Electric guitar" is new, "guitar" covers them both, but you sometimes need a way to specify "acoustic".  Right now target configurations we're talking about include:
>>> 
>>> 1. Booting all your domains directly from Xen using DT configurations
>>> 2. Booting a domB, which then executes some more complicated programmatic configuration to launch VMs before disappearing
>>> 3. Doing full measured boot on the whole system using a domB.
>>> 
>>> If "Hyperlaunch" means 1-3, we not only need a way to specify that you're talking about 3, but *also* a way to specify that you're talking about 1.  In the vast majority of cases for the foreseeable future are going to be 1.  Additionally, we want to make sure that "Hyperlaunch" *actually* turns out to mean 1-3, and not just 1.
>>> 
>>> The thing I like about "Hyperlaunch DT" is that to me it sounds pretty cool but also is very descriptive: I haven't talked to people building these systems, but it seems like saying, "The hypervisor launches VMs based on a Device Tree passed to it at boot" will be immediately understood, and stick in people's minds.
>> Personally, I like the name “Hyperlaunch DT”, because it tells me that we are launching VMs and the DT is involved, if I understood correctly the design,
>> it would be the same also on x86 (and in every architecture that will come later) so being “Hyperlaunch DT” an arch agnostic name makes it a good
>> candidate for phase out dom0less name and for the future when a common code will use the DT to launch VMs at Xen boot.
> 
> I assume that DT means Device-Tree here. If so, I find a name a bit misleading because we are talking about the way to pass the configuration rather than what the feature is doing.
> 
> My assumption here is that a DomB solution would still use the Device-Tree to describe the domains.

The sentence below makes sense to me, “DT”, “domB/Boot/Boot Domain/BD”, “Measured Boot/MB” can do the work of distinguish the functionalities, even if the Device tree is involved in all of them.

>>>> Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device Tree" (without the involvement of a domB), "Hyperlaunch Boot Domain /
>>>> Hyperlaunch domB" for a more general "domB" functionality, and "Hyperlaunch Measured Boot" for the full functionality (assuming there's
>>>> more to this than simply having a domB involved)?


At least in my personal opinion, we have people that worked a lot more than me on this project so they can know better.


> 
> Cheers,
> 
> -- 
> Julien Grall
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Julien Grall 9 months, 3 weeks ago 
Hi,

On 06/07/2023 14:04, Luca Fancellu wrote:
> 
>>>>>
>>>>> The "start VMs from Xen on boot" functionality is the *only* thing that a big chunk of the users of this functionality want;  referring to
>>>>> it as "Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the value of the functionality.
>>>>>
>>>>> What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured Boot" to refer to the full measured boot functionality?
>>>>
>>>> I think this is the best way.
>>>>
>>>>
>>>>> Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device Tree" (without the involvement of a domB), "Hyperlaunch Boot Domain /
>>>>> Hyperlaunch domB" for a more general "domB" functionality, and "Hyperlaunch Measured Boot" for the full functionality (assuming there's
>>>>> more to this than simply having a domB involved)?
>>>>
>>>>
>>>> We need an overarching name to cover the feature "start VMs from Xen on
>>>> boot" on both ARM and x86. From my understanding and from the original
>>>> emails on the subject, the name "hyperlaunch" was it.
>>>>
>>>> Sure; but think "guitar" vs "acoustic guitar" vs "electric guitar".  "Electric guitar" is new, "guitar" covers them both, but you sometimes need a way to specify "acoustic".  Right now target configurations we're talking about include:
>>>>
>>>> 1. Booting all your domains directly from Xen using DT configurations
>>>> 2. Booting a domB, which then executes some more complicated programmatic configuration to launch VMs before disappearing
>>>> 3. Doing full measured boot on the whole system using a domB.
>>>>
>>>> If "Hyperlaunch" means 1-3, we not only need a way to specify that you're talking about 3, but *also* a way to specify that you're talking about 1.  In the vast majority of cases for the foreseeable future are going to be 1.  Additionally, we want to make sure that "Hyperlaunch" *actually* turns out to mean 1-3, and not just 1.
>>>>
>>>> The thing I like about "Hyperlaunch DT" is that to me it sounds pretty cool but also is very descriptive: I haven't talked to people building these systems, but it seems like saying, "The hypervisor launches VMs based on a Device Tree passed to it at boot" will be immediately understood, and stick in people's minds.
>>> Personally, I like the name “Hyperlaunch DT”, because it tells me that we are launching VMs and the DT is involved, if I understood correctly the design,
>>> it would be the same also on x86 (and in every architecture that will come later) so being “Hyperlaunch DT” an arch agnostic name makes it a good
>>> candidate for phase out dom0less name and for the future when a common code will use the DT to launch VMs at Xen boot.
>>
>> I assume that DT means Device-Tree here. If so, I find a name a bit misleading because we are talking about the way to pass the configuration rather than what the feature is doing.
>>
>> My assumption here is that a DomB solution would still use the Device-Tree to describe the domains.
> 
> The sentence below makes sense to me, “DT”, “domB/Boot/Boot Domain/BD”, “Measured Boot/MB” can do the work of distinguish the functionalities, even if the Device tree is involved in all of them.

Throwing another name we discussed today at the pub. How about: 
"Hyperlaunch static"

This would indicate the domains have been statically configured whereas 
I guess the one from DomB may be more dynamic?

-- 
Julien Grall
Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
Posted by Luca Fancellu 9 months, 4 weeks ago 

> On 3 Jul 2023, at 21:54, P S <pairspace@gmail.com> wrote:
> 
> 
> 
>> On Jul 3, 2023, at 15:45, Luca Fancellu <luca.fancellu@arm.com> wrote:
>> 
>> 
>> 
>>> On 3 Jul 2023, at 18:48, Stefano Stabellini <sstabellini@kernel.org> wrote:
>>> 
>>>> On Mon, 3 Jul 2023, Daniel P. Smith wrote:
>>>> On 7/1/23 11:13, Luca Fancellu wrote:
>>>>>> On 1 Jul 2023, at 08:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>>>> 
>>>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote:
>>>>>>> The "dom0less" feature was intended to be the feature where a domU
>>>>>>> domain could be launched without the control domain (Dom0)
>>>>>>> intervention, however the name seems to suggest that Dom0 cannot
>>>>>>> be part of the configuration, while instead it's a possible use case.
>>>>>>> 
>>>>>>> To avoid that, rename the "dom0less" configuration with the name
>>>>>>> "hyperlaunch", that is less misleading.
>>>>>>> 
>>>>>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
>>>>>>> ---
>>>>>>> This is an RFC to get the feeling of the community about the name
>>>>>>> change, for now it's everything in one patch just to see how it
>>>>>>> will look like, if there is interest on proceeding into it, I can
>>>>>>> split in more commit.
>>>>>> 
>>>>>> Have you discussed this with Dan and Chris at all?  You haven't even
>>>>>> CC'd them.
>>>>> 
>>>>> No, this rename idea started from a chat during the summit, anyway Julien
>>>>> promptly add them to the CC, because I forgot.
>>>> 
>>>> No worries and thank you for considering and taking the time to do this RFC.
>>>> It is greatly appreciated that there is a strong willingness to have dom0less
>>>> and hyperlaunch merged.
>>>> 
>>>>>> 
>>>>>> While there is a lot of end-goal in common between the dom0less and
>>>>>> hyperlaunch, and that the name dom0less is deeply misleading,
>>>>>> hyperlaunch is specifically not this.
>>>>> 
>>>>> Yes Hyperlaunch is more than this, however as I said, with this RFC I would
>>>>> like
>>>>> to ear opinions, @Daniel @Christopher could it be a proper name for the
>>>>> dom0less
>>>>> feature?
>>>> 
>>>> As Andy has alluded, hyperlaunch is meant to provide a flexible means to
>>>> handle domain construction at boot to meet a wide range of possible use cases.
>>>> One of those use cases is dom0less, so yes, ultimately what dom0less does
>>>> today will be achievable under hyperlaunch. Our intended approach to align the
>>>> two implementations is one that is meant to be minimally disruptive, since
>>>> dom0less is considered a supported (SUPPORT.md) capability. As mentioned, we
>>>> are greatly appreciative to the openness to adopt the name,
>>> 
>>> Thanks Daniel!
>>> 
>>> 
>>>> but a big concern
>>>> I personally have is the confusion it could cause a general user. A blanket
>>>> rename would end up with two documents in the docs tree that provide two
>>>> different explanations of hyperlaunch and two different device tree
>>>> definitions. So I think a more measured approach should be considered here.
>>>> 
>>>>> If this patch makes things more difficult for the Hyperlunch serie, I’m ok
>>>>> to drop it,
>>>>> my only aim was just to find a less misleading name for the feature.
>>>> 
>>>> What I would like to suggest as a good first step would be an update to the
>>>> dom0less document. Provide a note at the beginning that points to the
>>>> hyperlaunch design doc as a more general approach that will eventually subsume
>>>> dom0less. This would provide a gentler transition for exist users of dom0less.
>>>> 
>>>> If it is not too much, I would also ask, please have a look at the design for
>>>> boot modules in the series Christopher just posted. The design pulls from the
>>>> work done by dom0less and expanded upon it. I major step into merging the two
>>>> capabilities will be to have a common set of structures. Once those are in
>>>> place, we can move to a common device tree representation, and at that point
>>>> we would be fairly close, if not at the point of a formal merger of between
>>>> the two.
>>> 
>>> At the moment we have a concrete problem with explaining dom0less and
>>> hyperlaunch to potential new users. Using two different names for a
>>> similar feature on arm and x86 causes confusion. It is hurting Xen as a
>>> solution. Personally I already had to switch to use the word
>>> "hyperlaunch" for everything in my users-facing presentations.
>>> 
>>> At the summit, we discussed that it would be a good idea to use a single
>>> name to refer to both features on arm and x86. Given that "dom0less"
>>> causes additional issues because it makes people think that there is no
>>> Dom0, the suggestion was to use "hyperlaunch" to refer to both features.
>>> 
>>> We don't need to 100% align the two implementations and data structures.
>>> This is not for engineers that are going to look at the specifications
>>> and improve them. This is for users/customers of Xen that are trying to
>>> understand what the hypervisor enables them to do. We need to be able to
>>> show users architecture slides with the same name and explanation on
>>> both ARM and x86.
>>> 
>>> I am sure that Daniel and Christopher remember, but for the others on
>>> this email thread, the name "hyperlaunch" was born exactly to be that:
>>> the one name to cover both features on ARM and x86 even if they have a
>>> different implementation. Appended an old email for reference.
>>> 
>>> Also I agree with Daniel that we need to be careful about the two docs
>>> under docs/. I think he is right we need to add a paragraph explaining
>>> the history and a pointer to the other document. Something like:
>>> 
>>> "Dom0less is the name that was used when initially introducing the
>>> feature on ARM. Then, the "dom0less" name was retired in favor of
>>> "hyperlaunch" to avoid confusion (a Dom0 might still be present) and to
>>> align with x86 (where a similar feature was called hyperlaunch from the
>>> start)."
>> 
>> I’m fully ok to add a section like this pointing to the Hyperlaunch design.
> 
> _If_ this text is added, please include links/references to the Hyperlaunch wiki page and Hyperlaunch design docs.
> 
>> @Daniel and @Christopher would it be ok for you or the changes in the serie
>> are going to be problematic for your future work? In the end it’s just a mechanical
>> rename, so I guess we just need to agree on naming conventions.
> 
> Please see the history of trademark litigation about the use of symbolic names to reference similar-but-different artifacts.  It is much easier to use the same name to refer to entirely different objects. Historically, confusion arises when a name is used in similar contexts.
> 
> There is also versioning.  Could we refer to dom0less as "Hyperlaunch Version -1"? 
> 
> How about renaming dom0less to "Hyperlaunch Lite"?

I’m ok as long as the Arm maintainer are happy with it

> 
> Rich
> 
>> Cheers,
>> Luca
>> 
>>> 
>>> 
>>> ---
>>> 
>>> Subject: [RFP] Overarching name for dom0less and DomB
>>> 
>>> Greetings,
>>> 
>>> At the DeviceTree/DomB meeting it was proposed that a new, larger
>>> overarching name under which DomB and dom0less would be covered. There
>>> was a general openness to the idea. As such, since Christopher and
>>> myself are in the midst of finalizing the design document for DomB we
>>> felt it might be better to see if a name could be selected which we
>>> could use in the design doc in lieu of DomB. As always naming things is
>>> hard, but after some brainstorming we believe we have arrived at a
>>> decent name, μLaunch (micro-Launch or uLaunch).
>>> 
>>> ---
>>> 
>>> μLaunch became hyperlaunch few days after, and the rest was history :-)
>> 
>>

Patchew 2.1-devel-0870f84

© 2016 - 2024 Red Hat, Inc.