> Subject: Re: UEFI support in ARM DomUs
> 
> 
> On 6/24/20 10:07 AM, Peng Fan wrote:
> >> Subject: Re: UEFI support in ARM DomUs
> >>
> >>
> >> On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote:
> >>> On 6/23/20 4:20 AM, Stefano Stabellini wrote:
> >>>> On Mon, 22 Jun 2020, Julien Grall wrote:
> >>>>>>>> For the first part (__XEN_INTERFACE_VERSION__) I think we can
> >>>>>>>> provide it via
> >>>>>>>>
> >>>>>>>> CFLAGS or something. This can also be done for the location of
> >>>>>>>> Xen headers.
> >>>>>>> __XEN_INTERFACE_VERSION__ should work through the CFLAGS.
> An
> >>>>>>> alternative would be to allow the user to specify through the
> Kconfig.
> >>>>>> You mean specifying via Kconfig something like "0x00040d00"?
> >>>>> Possibly yes.
> >>>>>
> >>>>>> And what about the headers? How will we provide their location if
> >>>>>> we decide not to include those
> >>>>>>
> >>>>>> in the tree?
> >>>>> I would do through Kconfig as well.
> >>>> If we specify the external location of the Xen headers via Kconfig,
> >>>> it seems to me that we should be able to detect the interface
> >>>> version automatically from any Makefile as part of the build. No
> >>>> need to ask the user.
> >>>>
> >>>> However, if Oleksandr is thinking of using the Xen headers for the
> >>>> hypercalls definitions, then I think we might not need external
> >>>> headers at all because that is a stable interface, as Julien wrote.
> >>>> We could just define our own few headers for just what you need
> >>>> like Linux
> >> does.
> >>> This is a good idea: I'll try to get the minimal set of headers from
> >>> Linux
> >>>
> >>> instead of Xen as those seem to be well prepared for such a use-case.
> >>> This
> >>>
> >>> way we'll have headers in U-boot tree and guarantee that we have a
> >>> minimal
> >>>
> >>> subset which is easier to maintain. I'll keep you updated on the
> >>> progress
> >> We've managed to strip the headers and remove __XEN__ and the rest
> >> definitions
> >>
> >> we were talking about. So, these are now the minimal required set of
> >> headers
> >>
> >> that allows U-boot to build serial and block drivers. Please take a
> >> look at [1]
> >>
> >> Pull request for comments is at [2]
> > The U-Boot new merge window will be open in 2020/7/1, so I'd suggest
> > the patchset goes to U-Boot mail list for discussion if you wanna the
> > patches gonna merged soon.
> 
> We definitely want the patches to be upstreamed and merged, but before
> that
> 
> we also want to make sure that Xen community is happy with what we
> upstream
> 
> I believe we resolved most of the concerns such as headers, PIE etc, so this
> can
> 
> be done.
> 
> BTW, Peng, did you have a chance to try the pvblock driver yet?

Not yet. I could have time to give a test next Monday. I think you not
enable SPL, right? So android dual bootloader feature not enabled.
But SPL mostly not have MMU enabled..

Regards,
Peng.

> 
> >
> > Regards,
> > Peng.
> >
> >>>> If you can do that, I think it would be better because we decouple
> >>>> the UBoot build from the Xen build completely. We don't even need
> >>>> the Xen tree checked out to build UBoot. It would be a huge
> >>>> advantage because it makes it far easier to build-test changes for
> >>>> others in the community that don't know about Xen and also it
> >>>> becomes far easier to integrate into any build system.
> >> [1]
> >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldef
> ense.com%2Fv3%2F__https%3A%2F%2Feur01.safelinks.protection.outlook.c
> om%2F%3Furl%3Dhttps*3A*2F*2Fgithub__%3BJSUl!!GF_29dbcQIUBPA!mwi
> b3un6-vYBG68zMfurW6-0MuuER5tNmJtOitDpViICNkX0lhig8iPHmZokuM-BLQ
> YpeKYAGQ%24&data=02%7C01%7Cpeng.fan%40nxp.com%7C950d9c0a
> dc514927ce8b08d8180ea4ef%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
> 0%7C0%7C637285798460563914&sdata=fMrI%2FQotknCsXV0amC4BFl
> 1Hg4vPw3zOMVdAVim2Wcs%3D&reserved=0 .
> >>
> com%2Fandr2000%2Fu-boot%2Ftree%2Fpvblock_upstream_v1&data=0
> >>
> 2%7C01%7Cpeng.fan%40nxp.com%7C407d8af24a36483fbdce08d81805ed88
> >> %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637285761021
> 975
> >>
> 164&sdata=5vWfBbLScICXPZWU%2BU3b7DyONcgxT8iICsxrwUbORZY%
> >> 3D&reserved=0
> >>
> >> [2]
> >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldef
> ense.com%2Fv3%2F__https%3A%2F%2Feur01.safelinks.protection.outlook.c
> om%2F%3Furl%3Dhttps*3A*2F*2Fgithub__%3BJSUl!!GF_29dbcQIUBPA!mwi
> b3un6-vYBG68zMfurW6-0MuuER5tNmJtOitDpViICNkX0lhig8iPHmZokuM-BLQ
> YpeKYAGQ%24&data=02%7C01%7Cpeng.fan%40nxp.com%7C950d9c0a
> dc514927ce8b08d8180ea4ef%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
> 0%7C0%7C637285798460563914&sdata=fMrI%2FQotknCsXV0amC4BFl
> 1Hg4vPw3zOMVdAVim2Wcs%3D&reserved=0 .
> >>
> com%2Fxen-troops%2Fu-boot%2Fpull%2F2&data=02%7C01%7Cpeng.fa
> >>
> n%40nxp.com%7C407d8af24a36483fbdce08d81805ed88%7C686ea1d3bc2b4
> >>
> c6fa92cd99c5c301635%7C0%7C0%7C637285761021975164&sdata=%2
> >>
> FmXheEvKssLjjaFKsHBBbqh%2B72jH3uQnE7cpN0J3k8I%3D&reserved=0

Reply via email to