Hi Luca,
On 07/09/2021 14:30, Luca Fancellu wrote:
On 7 Sep 2021, at 13:30, Julien Grall <jul...@xen.org> wrote:
On 07/09/2021 12:51, Luca Fancellu wrote:
On 7 Sep 2021, at 10:35, Julien Grall <jul...@xen.org> wrote:
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?
Here I’m lost, because I don’t understand what we are going to do with the name
of the binary.
<binaryX> would be used by the UEFI stub to load the binary in memory. Each binary
will have a <keyX> which helps to refer them in the Device-Tree. To give a concrete
example, let say we have two dom0less domains:
- DomA: 2 vCPUs, 128MB
- DomB: 3 vCPUs, 512MB
DomA and DomB will be using the same kernel but a different ramdisk. xen.cfg,
would look like:
[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
binary=vmlinuz-guest domu-kernel
binary=ramdisk-domA.img domA-ramdisk
binary=ramdisk-domB.img domB-ramdisk
The chosen node in the DT would look like:
chosen {
domU1 {
compatible = "xen,domain";
#address-cells = <0x2>;
#size-cells = <0x1>;
memory = <0 0x8000000>;
cpus = <2>;
module@1 {
compatible = "multiboot,kernel", "multiboot,module";
uefi,binary = "domu-kernel";
bootargs = "console=ttyAMA0 init=/bin/sh";
};
module@2 {
compatible = "multiboot,ramdisk", "multiboot,module";
uefi,binary = "domA-ramdisk";
};
};
domU2 {
compatible = "xen,domain";
#address-cells = <0x3>;
#size-cells = <0x1>;
memory = <0 0x20000000>;
cpus = <3>;
module@1 {
compatible = "multiboot,kernel", "multiboot,module";
uefi,binary = "domu-kernel";
bootargs = "console=ttyAMA0 init=/bin/sh";
};
module@2 {
compatible = "multiboot,ramdisk", "multiboot,module";
uefi,binary = "domA-ramdisk";
};
};
};
With this approach, the change is quite minimal to move between an classic
U-boot boot and EFI boot.
Ok now I see, yes this approach can work and can save some code, in the current
code we have that if
a "multiboot,module” is found in the dtb, the Xen EFI configuration file is
skipped, but if we use the
module@XX {} without the compatible it can work, the UEFI stub will load the
binary and update all
the needed properties (compatible, reg).
With my proposal, you don't know whether the binary is a kernel,
ramdisk... So you wouldn't be able to recreate the compatible properly.
But the behavior of the UEFI stub can be modified. We could say that if
there is a "xen,domain" then use the configuration file to fetch the
binaries.
Cheers,
--
Julien Grall
