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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.09.2021 13:51, Luca Fancellu wrote:
>> On 7 Sep 2021, at 10:35, Julien Grall <julien@xxxxxxx> wrote:
>> On 07/09/2021 07:52, Luca Fancellu wrote:
>>> --- /dev/null
>>> +++ b/docs/designs/efi-arm-dom0less.md
>>> @@ -0,0 +1,105 @@
>>> +# Xen EFI configuration file
>>> +
>>> +The current configuration file used by Xen when it is started as an EFI
>>> +application is considering only the dom0 guest and doesn't have any
>>> +property to describe and load in memory domU guests.
>>
>> From my understanding, the problem is less about properties (we already have 
>> them in the Device-Tree) but more about where are the binaries located in 
>> memory as we don't know in advance.
> 
> I think I used the wrong word there, I meant “keyword” instead of “property” 
> because I was referring about the
> lack of keywords to describe a domu guest in the Xen EFI configuration file.
> 
> I agree with you that on systems with static allocation, the kernel and 
> ramdisk binaries must be at certain locations
> that are out of control when we use the EFI boot services, the thing we can 
> do is provide a keyword to specify the
> addresses and then use the CopyMem() function to relocate the kernel/ramdisk 
> in the address we want.
> 
>>
>> So I would like to propose something that build on top of the Device-Tree 
>> work we did. Note this is early thoughts.
>>
>> The problematic nodes in the DT are:
>>
>>        module@0x4a000000 {
>>            compatible = "multiboot,kernel", "multiboot,module";
>>            reg = <0x0 0x4a000000 0xffffff>;
>>            bootargs = "console=ttyAMA0 init=/bin/sh";
>>        };
>>
>>        module@0x4b000000 {
>>            compatible = "multiboot,ramdisk", "multiboot,module";
>>            reg = <0x0 0x4b000000 0xffffff>;
>>        };
>>
>> In particular the property "reg" cannot be known in advance because the UEFI 
>> stub will be responsible to load the binaries in memory.
> 
> Yes that’s true, the UEFI stub is using from the UEFI boot service the 
> AllocatePages function that is giving back an address out of our control,
> then using another function the binary is read from the disk and copied at 
> that address, finally the UEFI stub is writing the node in the device tree 
> that
> will be used by Xen later.

If you know the intended address is available, AllocatePages() can very well
be given a pre-determined address via the AllocateAddress allocation type.

Jan