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

[Julien Grall <julien@xxxxxxx>]

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:
> >
> > [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