[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On 07/09/2021 09:33, Jan Beulich wrote:
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
+Here an example:
+options=console=vga,com1 com1=57600 loglvl=all noreboot
+kernel=vmlinuz-3.0.31-0.4-xen [domain 0 command line options]
+# 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:
+      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 
+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
+# Example of a configuration file describing a dom0less system
+The following configuration file is describing a dom0less system starting two
+# Xen boot arguments
+options=noreboot console=dtuart dtuart=serial0 bootscrub=0
+# Xen device tree
+# Guest 1
+domu1_kernel=Image-domu1.bin console=ttyAMA0 root=/dev/ram0 rw
+# Guest 2
+domu2_kernel=Image-domu2.bin console=ttyAMA0 root=/dev/ram0 rw

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:

kernel=Image-domu1.bin console=ttyAMA0 root=/dev/ram0 rw

I much prefer the idea of the section. This is going to be easier to parse the configuration file as we would not have to look for "domuX_" and then distinguishing X.

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:


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).

I would expect dom0 to be described in the similar fashion at some point. So maybe we should name the property "domains=...".

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

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

It depends on the number of properties for the domain, this may become quickly unreadable.

But... if we use sections, then I think it would be better to have:


This would also allow us to create more complex setup (such as for the static memory allocation).


Julien Grall



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.