Re: UEFI support in ARM DomUs

[Julien Grall <julien@xxxxxxx>]

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
> 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).
One question though, why do you need to map them in advance? Couldn't 
you map them on demand?
Cheers,

--
Julien Grall