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

[Luca Fancellu <luca.fancellu@xxxxxxx>]

> On 7 Sep 2021, at 15:18, Julien Grall <julien@xxxxxxx> wrote:
> 
> 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.

Yes you are right, or we can introduce domu_kernel, domu_ramdisk, domu_dtb with 
the same syntax of your binary= keyword, that would be enough
to select the right compatible, instead the right module is identified by the 
string.

> 
> Cheers,
> 
> -- 
> Julien Grall