Re: UEFI support in ARM DomUs

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

On 6/19/20 3:47 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 19/06/2020 13:32, Oleksandr Andrushchenko wrote:
>>
>> On 6/19/20 1:49 AM, Julien Grall wrote:
>>> On Thu, 18 Jun 2020 at 23:00, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
>>> wrote:
>>>> On Thu, 18 Jun 2020, Julien Grall wrote:
>>>>> On 18/06/2020 06:22, Oleksandr Andrushchenko wrote:
>>>>>> On 6/4/20 6:31 PM, Stefano Stabellini wrote:
>>>>>>> On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote:
>>>>>>>> On 6/4/20 4:57 AM, Peng Fan wrote:
>>>>>>>>> Grall <julien@xxxxxxx>;
>>>>>>>>>> Nataliya Korovkina <malus.brandywine@xxxxxxxxx>
>>>>>>>>>> Subject: UEFI support in ARM DomUs
>>>>>>>>> We have made U-Boot run inside XEN DomU, but just only PV console
>>>>>>>>> part,
>>>>>>>>> not implement other frontend drivers currently. Would this help for
>>>>>>>>> your
>>>>>>>>> case if enable EFI in U-Boot?
>>>>>>>> Well, we have a working PV block implementation on top of that on iMX8
>>>>>>>>
>>>>>>>> platform, mostly ported from mini-os. Currently we are finalizing the
>>>>>>>> work
>>>>>>>>
>>>>>>>> and cleaning up (it's going to take a week or so hopefully). Then, we
>>>>>>>> we'll post
>>>>>>>>
>>>>>>>> it on our public github. We are also thinking about upstreaming the
>>>>>>>> work, but it may
>>>>>>>>
>>>>>>>> take quite some time if the whole idea fits u-boot's view on such an
>>>>>>>> extension at all.
>>>>>>> Yes please to both of you! :-)
>>>>>>>
>>>>>>> In the meantime, while we wait for those changes to go upstream in
>>>>>>> uboot, could you please post a branch on github and a link on this email
>>>>>>> thread?
>>>>>> It took a bit more time than we expected, but here we go [1]:
>>>>>>
>>>>>> this is in form of a pull-request as we would love to hear from the
>>>>>>
>>>>>> community and it is easier to discuss the code (please leave comments 
>>>>>> there)
>>>>>>
>>>>>> 1. There is code originating from MiniOS and work done by Peng, so we
>>>>>>
>>>>>> would like to ask the respective copyright owners to raise their hands 
>>>>>> and
>>>>> Not everyone are closely watching xen-devel. So if you want to find out 
>>>>> who
>>>>> are the copyright owners, then your best solution is to go through the 
>>>>> git log
>>>>> and CC the authors.
>>>> That is true. But why do you want to contact them? It doesn't look like
>>>> there would be any licensing issues.
>>>   From the sentence, I wasn't entirely sure whether he wanted to contact
>>> the copyright owner for crediting them in the headers.
>>>
>>>>>> 5. We use -D__XEN__ to access some of the hidden defines we need such as
>>>>>>
>>>>>> GUEST_RAM0_BASE and the friends as there is no other way but manually
>>>>>> defining the
>>>>>>
>>>>>> same which is not cute.
>>>>> I have replied to this in the pull request. But I want to bring the
>>>>> conversation here to have a wider discussion.
>>>>>
>>>>> For a first, __XEN__ should really only be defined by the hypervisor and 
>>>>> not
>>>>> used by the guest. This is used to gate non-stable ABI (such as the 
>>>>> tools) and
>>>>> anything behind it hasn't been vetted to work in other build configuration
>>>>> that the one used by Xen.
>>>>>
>>>>> In general, we expect the guest to discover everything for the device-tree
>>>>> because the memory layout is not stable (we want to be able to reshuffle 
>>>>> as we
>>>>> add more features).
>>>>>
>>>>> I know that EDK2/Tianocore can be built once and work on every Xen
>>>>> configuration. It would be ideal that U-boot follow the same. If it is 
>>>>> really
>>>>> not possible, then we should explore a path that is preventing to define
>>>>> __XEN__.
>>>>>
>>>>> How much does U-boot expect to know about the memory layout? Does it 
>>>>> require
>>>>> to know all the memory banks? Or would it be sufficient for it to know the
>>>>> start address of the first bank and the minimum of RAM?
>>>> Copy/pasting here from my comment on the pull request plus additional
>>>> thoughts.
>>>>
>>>> Uboot is one of those embedded projects that typically assumes that all
>>>> the information about the platform is available at *build time*. It is
>>>> meant to be built tailored for a specific version of a specific board. A
>>>> Uboot binary is not expected to be "portable" across different versions
>>>> of the platform or different platforms. In other words, it is not
>>>> expected to be portable across Xen versions.
>>> Can you define "version" here? Do you refer to the difference in terms
>>> of memory?
>>>
>>>> This is a different model meant for different use-cases. I don't think
>>>> it is a problem "philosophically" to let Uboot know about Xen details at
>>>> build time. Yes, that is not what we did historically but it is very
>>>> much in the spirit of Uboot.
>>> TBH, I don't particularly mind that U-boot is built against a specific
>>> version of Xen. I am more concerned about the long term implication if
>>> we endorse it
>>> and then try to change the memory layout in depth.
>>>
>>>> But of course the least Uboot depends on these details the better
>>>> because it will be more flexible, but it could very well be that we
>>>> won't be able to reach the point where the binary works on any version
>>>> like we did with Tianocore. The two projects work differently.
>>> Can we have a list of things U-boot require to know at compile time?
>>>
>>> In particular, I would like to understand if it would be sufficient to
>>> only be aware of the first bank. If it is, then my preference would be
>>> to standardize that bit of the layout.
>>
>> Well, my bad, I was not right about PIE. We are lucky that it is supported
>>
>> for ARM64, so we can avoid using GUEST_RAM0_BASE.
>
> Cool!
>
>>
>> With respect to the number of banks I see no big issue if we do not use
>>
>> GUEST_RAM_BANKS, but set it to 1.
>
> I am guessing U-boot wouldn't be able to load modules into the second bank. 
> Am I corre
Not sure, but this can be the case
>> The last thing at the moment that I am not sure of is 
>> GUEST_MAGIC_{BASE|SIZE}:
>>
>> those can be retrieved from the device tree and I'll have to check if
>>
>> fdt is available at the very early boot stage so we can get that when it is 
>> needed.
>
> They will not be available from the fdt, but you can retrieve them with an 
> hypervisor call (see HVM_PARAM_STORE_PFN, HVM_PARAM_CONSOLE_PFN).
Yes, and it used in the relevant pieces of code (hyp calls)
> One question though, why do you need to map them in advance? Couldn't you map 
> them on demand?

Well, we need to at least estimate the pg_table size so we can reserve and 
allocate memory later,

so I have to provide memory range from either by coding a constant or looking 
into the devtree at

hypervisor { reg = <>; }. It is a bit tricky though

> Cheers,
>