Re: [RFC PATCH] xen/design: Add design for EFI dom0less system start

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.09.2021 08:52, Luca Fancellu wrote:
> Add a design describing a proposal to improve the EFI
> configuration file, adding keywords to describe domU
> guests and allowing to start a dom0less system.
> 
> Signed-off-by: Luca Fancellu <luca.fancellu@xxxxxxx>
> ---
>  docs/designs/efi-arm-dom0less.md | 105 +++++++++++++++++++++++++++++++
>  1 file changed, 105 insertions(+)
>  create mode 100644 docs/designs/efi-arm-dom0less.md
> 
> diff --git a/docs/designs/efi-arm-dom0less.md 
> b/docs/designs/efi-arm-dom0less.md
> new file mode 100644
> index 0000000000..8d8fa2243f
> --- /dev/null
> +++ b/docs/designs/efi-arm-dom0less.md
> @@ -0,0 +1,105 @@
> +# Xen EFI configuration file
> +
> +The current configuration file used by Xen when it is started as an EFI
> +application is considering only the dom0 guest and doesn't have any
> +property to describe and load in memory domU guests.
> +Hence currently it's impossible to start a dom0less system using EFI.
> +
> +# Objective
> +
> +This document describes the proposed improvement to the Xen EFI
> +configuration file to list properly both the dom0 guest and the domU
> +guests as well.
> +The final goal is to be able to start a dom0less system using EFI.
> +
> +# Current Xen EFI configuration file
> +
> +The current configuration file is described by the documentation page
> +https://xenbits.xenproject.org/docs/unstable/misc/efi.html.
> +
> +Here an example:
> +
> +```
> +[global]
> +default=section1
> +
> +[section1]
> +options=console=vga,com1 com1=57600 loglvl=all noreboot
> +kernel=vmlinuz-3.0.31-0.4-xen [domain 0 command line options]
> +ramdisk=initrd-3.0.31-0.4-xen
> +xsm=<filename>
> +dtb=devtree.dtb
> +```
> +
> +# Proposed improvement
> +
> +The proposed improvement to the current configuration file is the
> +introduction of new keywords to describe additional domUs.
> +
> +Here follows the proposed new keywords:
> +  - domu#_kernel=<kernel file> [domU command line options]
> +    - Mandatory kernel file for the domU#
> +  - domu#_ramdisk=<ramdisk file>
> +    - Optional ramdisk file for the domU#
> +  - domu#_dtb=<dtb file>
> +    - Optional dtb fragment file for the domU#, it is used for device
> +      assignment (passthrough).
> +  - domu#_property=cpus=2
> +    - Properties that should be added to the dtb in the domU node to
> +      properly describe the domU guest. Refer to the documentation:
> +      
> https://xenbits.xenproject.org/docs/unstable/misc/arm/device-tree/booting.txt,
> +      section "Creating Multiple Domains directly from Xen".
> +
> +For all the keywords above, the # is a number that uniquely identifies
> +the guest.
> +The keywords domu#_kernel, domu#_ramdisk, domu#_dtb are unique, therefore 
> there
> +must not be specified the same keyword twice in a section.
> +The # number is not enforcing any domid, it is just used to link each 
> property
> +to the right guest, so there can be domu1_* guests that are started with 
> domid 2
> +and so on.
> +
> +The domu#_property can appear multiple times and it specifies an additional
> +property to be listed in the domU node inside the device tree, Xen will
> +not check if the same content is specified multiple times.
> +
> +There are some property whose name starts with an hash symbol 
> (#address-cells,
> +#size-cells), in this case the line will be considered as a comment, so to
> +specify them, they have to be listed without the hash symbol, the 
> documentation
> +will be updated as well to see the implemented handling of these special
> +properties.
> +
> +# Example of a configuration file describing a dom0less system
> +
> +The following configuration file is describing a dom0less system starting two
> +guests.
> +
> +```
> +[global]
> +default=xen
> +
> +[xen]
> +# Xen boot arguments
> +options=noreboot console=dtuart dtuart=serial0 bootscrub=0
> +# Xen device tree
> +dtb=devtree.dtb
> +
> +# Guest 1
> +domu1_property=address-cells=2
> +domu1_property=size-cells=2
> +domu1_kernel=Image-domu1.bin console=ttyAMA0 root=/dev/ram0 rw
> +domu1_property=cpus=1
> +domu1_property=memory=0xC0000
> +domu1_dtb=domu.dtb
> +
> +# Guest 2
> +domu2_kernel=Image-domu2.bin console=ttyAMA0 root=/dev/ram0 rw
> +domu2_property=cpus=2
> +domu2_property=memory=0x100000
> +domu2_property=vpl011
> +```

I'd like to suggest a different scheme, not the least because I expect
the individual domains being independent of e.g. hypervisor command
line options or Dom0 kernel versions. Yet varying sets of these are,
for example, a reason to have multiple sections in the current scheme.
Every dom0less guest would then require spelling out in every such
section. Hence I think we'd be better off having a section per guest:

[guest1]
kernel=Image-domu1.bin console=ttyAMA0 root=/dev/ram0 rw
property=cpus=1
property=memory=0xC0000
dtb=domu.dtb

These sections would then be referenced by other sections, e.g. by a
new "guests" (or "domus", but this ends up looking a little odd for
its matching of an unrelated latin word) keyword:

guests=guest1,guest2

If it is deemed necessary to make sure such a section can't be
(mistakenly) used to create Dom0, such sections would need identifying
in some way. Presence of property= (or, as per below, properties=)
could be one means (allowing an empty setting would then be desirable).

As to the properties, is there anything wrong with having them all on
one line:

[guest1]
kernel=Image-domu1.bin console=ttyAMA0 root=/dev/ram0 rw
dtb=domu.dtb
properties=cpus=1 memory=0xC0000

(just like is the case for options=)?

Jan