mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
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>
50 lines
2.2 KiB
Plaintext
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.
|