Files
xen/docs/features/dom0less.pandoc
T
Andrew Cooper d661611d08 docs/markdown: Switch to using pandoc, and fix underscore escaping
c/s a3a99df44 "docs/cmdline: Rewrite the cpuid_mask_* section" completely
forgot about how markdown gets rendered to HTML (as opposed to PDF), because
we use different translators depending on the destination format.

markdown and pandoc are very similar markup languages, but a couple of details
about pandoc cause it to have far more user-friendly inline markup.

Switch all markdown documents to be pandoc (so we are using a single
translator, and therefore a single flavour of markdown), which fixes the
rendered docs on xenbits.xen.org/docs.

While changing the format, fix the remainder of the escaped underscores in the
same mannor as the previous patch.  The two problem cases here are __LINE__
and __FILE__ where the first underscore still needs escaping.

In addition, dmop.markdown and dom0less.markdown didn't used to get processed,
as only .markdown files in the misc/ directory got considered.
dom0less.pandoc gets picked up automatically now, due to being in the
features/ directory, but designs/ needs adding to the pandoc directory list
for dmop.pandoc to get processed.

While edting in appropriate areas, take the opportunity to fix some markup to
the surrounding style, and drop trailing whitespace.

No change in content - only formatting.  This results in the text being easier
to read and grep.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
2019-01-02 17:50:36 +00:00

50 lines
2.2 KiB
Plaintext

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.