Re: UEFI support in ARM DomUs

From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>
Cc: Anastasiia Lukianenko <Anastasiia_Lukianenko@epam.com>,
	Juergen Gross <jgross@suse.com>, Peng Fan <peng.fan@nxp.com>,
	Oleksandr Andrushchenko <andr2000@gmail.com>,
	Roman Shaposhnik <roman@zededa.com>,
	Bertrand Marquis <Bertrand.Marquis@arm.com>,
	Nataliya Korovkina <malus.brandywine@gmail.com>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	Julien Grall <julien.grall.oss@gmail.com>
Subject: Re: UEFI support in ARM DomUs
Date: Wed, 24 Jun 2020 06:14:59 +0000	[thread overview]
Message-ID: <a122102d-c023-0379-5d2c-b7b08d262844@epam.com> (raw)
In-Reply-To: <271a4db0-5ce5-ba25-65e7-107c040f5069@epam.com>

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]

>
>>
>> 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://github.com/andr2000/u-boot/tree/pvblock_upstream_v1

[2] https://github.com/xen-troops/u-boot/pull/2