|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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? > > 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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub__;JSUl!!GF_29dbcQIUBPA!mwib3un6-vYBG68zMfurW6-0MuuER5tNmJtOitDpViICNkX0lhig8iPHmZokuM-BLQYpeKYAGQ$ >> . >> com%2Fandr2000%2Fu-boot%2Ftree%2Fpvblock_upstream_v1&data=0 >> 2%7C01%7Cpeng.fan%40nxp.com%7C407d8af24a36483fbdce08d81805ed88 >> %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637285761021975 >> 164&sdata=5vWfBbLScICXPZWU%2BU3b7DyONcgxT8iICsxrwUbORZY% >> 3D&reserved=0 >> >> [2] >> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub__;JSUl!!GF_29dbcQIUBPA!mwib3un6-vYBG68zMfurW6-0MuuER5tNmJtOitDpViICNkX0lhig8iPHmZokuM-BLQYpeKYAGQ$ >> . >> 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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |