On 07.09.2021 13:51, Luca Fancellu wrote:
>> On 7 Sep 2021, at 10:35, Julien Grall <jul...@xen.org> 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
