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

[Julien Grall <julien@xen.org>]

Hi Luca,

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