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.fance...@arm.com> > --- > 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
