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