Re: [Xen-devel] [PATCH v7b 03/25] xen/arm: document dom0less

[Julien Grall <julien.grall@xxxxxxx>]

Hi Stefano,

On 13/11/2018 17:51, Stefano Stabellini wrote:
> Add a new document to provide information on how to use dom0less related
> features and their current limitations.
>
> Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx>
Acked-by: Julien Grall <julien.grall@xxxxxxx>

Cheers,

> ---
> 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.
--
Julien Grall

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