[PATCH v7 03/25] xen/arm: document dom0less

[Stefano Stabellini <sstabellini@kernel.org>]

Add a new document to provide information on how to use dom0less related
features and their current limitations.

Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>

---
Changes in v5:
- convert to markdown
- move to docs/features
- add entry to docs/INDEX

Changes in v4:
- rename to .txt
- improve wording

Changes in v3:
- add patch
---
 docs/INDEX                      |  1 +
 docs/features/dom0less.markdown | 49 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+)
 create mode 100644 docs/features/dom0less.markdown

diff --git a/docs/INDEX b/docs/INDEX
index 868ab1f..e673edd 100644
--- a/docs/INDEX
+++ b/docs/INDEX
@@ -25,3 +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
diff --git a/docs/features/dom0less.markdown b/docs/features/dom0less.markdown
new file mode 100644
index 0000000..4e342b7
--- /dev/null
+++ b/docs/features/dom0less.markdown
@@ -0,0 +1,49 @@
+Dom0less
+========
+
+"Dom0less" 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.
+
+Booting Multiple Domains from Device Tree
+-----------------------------------------
+
+This feature enables Xen to create a set of DomUs at boot time.
+Information about the DomUs to be created by Xen is passed to the
+hypervisor via Device Tree. Specifically, the existing Device Tree based
+Multiboot specification has been extended to allow for multiple domains
+to be passed to Xen. See docs/misc/arm/device-tree/booting.txt for more
+information about the Multiboot specification and how to use it.
+
+Currently, a control domain ("dom0") is still required, but in the
+future it will become unnecessary when all domains are created
+directly from Xen. Instead of waiting for the control domain to be fully
+booted and the Xen tools to become available, domains created by Xen
+this way are started right away in parallel. Hence, their boot time is
+typically much shorter.
+
+Domains started by Xen at boot time currently have the following
+limitations:
+
+- They cannot be properly shutdown or rebooted using xl. If one of them
+  crashes, the whole platform should be rebooted.
+
+- Some xl operations might not work as expected. xl is meant to be used
+  with domains that have been created by it. Using xl with domains
+  started by Xen at boot might not work as expected.
+
+- The GIC version is the native version. In absence of other
+  information, the GIC version exposed to the domains started by Xen at
+  boot is the same as the native GIC version.
+
+- No PV drivers. There is no support for PV devices at the moment. All
+  devices need to be statically assigned to guests.
+
+- Pinning vCPUs of domains started by Xen at boot can be
+  done from the control domain, using `xl vcpu-pin` as usual. It is not
+  currently possible to configure vCPU pinning without a control domain.
+  However, the NULL scheduler can be selected by passing `sched=null` to
+  the Xen command line. The NULL scheduler automatically assigns and
+  pins vCPUs to pCPUs, but the vCPU-pCPU assignments cannot be
+  configured.
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel