Hi Luca,
On 07/09/2021 07: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.
From my understanding, the problem is less about properties (we already
have them in the Device-Tree) but more about where are the binaries
located in memory as we don't know in advance.
So I would like to propose something that build on top of the
Device-Tree work we did. Note this is early thoughts.
The problematic nodes in the DT are:
module@0x4a000000 {
compatible = "multiboot,kernel", "multiboot,module";
reg = <0x0 0x4a000000 0xffffff>;
bootargs = "console=ttyAMA0 init=/bin/sh";
};
module@0x4b000000 {
compatible = "multiboot,ramdisk", "multiboot,module";
reg = <0x0 0x4b000000 0xffffff>;
};
In particular the property "reg" cannot be known in advance because the
UEFI stub will be responsible to load the binaries in memory.
What we could do is providing a list of binaries to load and associate a
key for each of them. Something like:
binary=<binary> <key>
binary=<binary2> <key2>
....
We can then replace the property "reg" with a new property "uefi,key"
that will contain the name of the binary.
What do you think?
Cheers,
--
Julien Grall
