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

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

Hi Luca,

On 07/09/2021 14:30, Luca Fancellu wrote:
On 7 Sep 2021, at 13:30, Julien Grall <julien@xxxxxxx> wrote:
On 07/09/2021 12:51, Luca Fancellu wrote:
On 7 Sep 2021, at 10:35, Julien Grall <julien@xxxxxxx> 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:


options=console=vga,com1 com1=57600 loglvl=all noreboot
kernel=vmlinuz-3.0.31-0.4-xen [domain 0 command line options]
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.


Julien Grall



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