mirror of
https://github.com/xen-project/xen.git
synced 2026-10-29 10:40:03 +01:00
Stefano Stabellini
1c908181a6
Improve Dom0-less documentation: include a complete configuration example. Signed-off-by: Stefano Stabellini <stefanos@xilinx.com> Acked-by: Julien Grall <julien.grall@arm.com>
114 lines
3.9 KiB
Plaintext
114 lines
3.9 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.
|
||
|
||
|
||
Configuration
|
||
-------------
|
||
|
||
### Loading binaries into memory ###
|
||
|
||
U-Boot needs to load not just Xen, the device tree binary, the dom0 kernel and
|
||
ramdisk. It also needs to load the kernel and ramdisk of any additional domains
|
||
to boot. For example if this is the bootcmd for Xen and Dom0:
|
||
|
||
tftpb 0x1280000 xen.dtb
|
||
tftpb 0x0x80000 xen-Image
|
||
tftpb 0x1400000 xen.ub
|
||
tftpb 0x9000000 xen-rootfs.cpio.gz.u-boot
|
||
|
||
bootm 0x1400000 0x9000000 0x1280000
|
||
|
||
If we want to add one DomU with Image-DomU as the DomU kernel
|
||
and ramdisk-DomU as DomU ramdisk:
|
||
|
||
tftpb 0x1280000 xen.dtb
|
||
tftpb 0x80000 xen-Image
|
||
tftpb 0x1400000 xen.ub
|
||
tftpb 0x9000000 xen-rootfs.cpio.gz.u-boot
|
||
|
||
tftpb 0x2000000 Image-DomU
|
||
tftpb 0x3000000 ramdisk-DomU
|
||
|
||
bootm 0x1400000 0x9000000 0x1280000
|
||
|
||
|
||
### Device Tree configuration ###
|
||
|
||
In addition to loading the necessary binaries, we also need to advertise
|
||
the presence of the additional VM and its configuration. It is done via
|
||
device tree adding a node under /chosen as follows:
|
||
|
||
domU1 {
|
||
compatible = "xen,domain";
|
||
memory = <0x20000>;
|
||
cpus = 1;
|
||
vpl011;
|
||
|
||
module@2000000 {
|
||
compatible = "multiboot,kernel", "multiboot,module";
|
||
reg = <0x2000000 0xffffff>;
|
||
bootargs = "console=ttyAMA0";
|
||
};
|
||
|
||
module@30000000 {
|
||
compatible = "multiboot,ramdisk", "multiboot,module";
|
||
reg = <0x3000000 0xffffff>;
|
||
};
|
||
};
|
||
|
||
Where memory is the memory of the VM in KBs, cpus is the number of
|
||
cpus. module@2000000 and module@3000000 advertise where the kernel and
|
||
ramdisk are in memory.
|
||
|
||
See docs/misc/arm/device-tree/booting.txt for more information.
|
||
|
||
Limitations
|
||
-----------
|
||
|
||
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.
|