[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: UEFI support in ARM DomUs
> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |