[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UEFI support in ARM DomUs


  • To: Peng Fan <peng.fan@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>
  • From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Date: Wed, 24 Jun 2020 07:38:44 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Oz1Q2ocq/uRC88smFmfIpZof01SF/ZKN9cts21k2DmA=; b=hYoZO1q+MZcA8AkKb+H5Zgd0NNe+3Q03EGfEXe3RSn/1FOFpamNr0X8hDKoIdwfEEQGSIS4k4j/pVXzrLA6cjPo6JR+M8Lfo7F2saj9YM2M+7H3T6zdztvZ/XwcUOxj4H3N1EbjEsxW+RVbzBB7aVadgQbarnYPWVYa+DPtNlYJA0E6PHsQDl4/QRZuaGiDIQZNBLoZ/nBDOpxGab0+ixJLJkYJrLA4HG978ck/kDinNoHXdctGb++JB5Tq9l5bBH+BjSTf4UVO1fh5KnhzQl4romTjRm9s/6km2aq1/Witb6yYRdsrCv9cRfAnNm/iojoXcbSMA4g41CmpZKO1PdQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BlMYCRVTpZYZS70lF0PdFrDxP/JszeEJMUpVR5l90gd4k1ZoMewM7LQAJUzsR3FhPbxWZe8LbWbScf4Mvq1GRES6BNVH+a54aE1/o2/wgz9fJblycs46nDSyEWlPCNa1JezKFaDLb2IBFsdIVvrZr/FOBxobExs7wbXE3wtHLQ+igsFCmlXJwNrkN9f8hQ8ju4G4dpgxvZT2PoVd6tlhCoBGyBoT9tOV7cf6rVG6rDH1BlL3IdBKlHe3FFZ3JxXecvOs9DA8OjAGVkU8Yd3GU04IGLzm4/kXlhocf3cuJK/dUpBEhFD6MO7DG0fZAXFSTkmqCxM9ODlKvtDDdUwsKQ==
  • Authentication-results: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=epam.com;
  • Cc: Anastasiia Lukianenko <Anastasiia_Lukianenko@xxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Oleksandr Andrushchenko <andr2000@xxxxxxxxx>, Roman Shaposhnik <roman@xxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Nataliya Korovkina <malus.brandywine@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Julien Grall <julien.grall.oss@xxxxxxxxx>
  • Delivery-date: Wed, 24 Jun 2020 07:38:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwCAAJ62gIAAeBOAgAANxQCAAWPDgIAEUtgAgAAGgYCAAAHAgIAANpaAgAB+IgCAAEYyAIABnlyAgAAOqgCAAALEAIAAAnuAgAADfIA=
  • Thread-topic: UEFI support in ARM DomUs

On 6/24/20 10:26 AM, Peng Fan wrote:
>> 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?

No, we decided that we can run with U-boot proper, so we can have more

flexibility comparing to what we have in SPL. It seems that was the right

approach: you can jump to Linux or you can jump to the U-boot provided

by Android anyway, whatever your setup

>   So android dual bootloader feature not enabled.

I think this step will depend on the use-case you have: at the moment we have

a base build capable of booting Linux kernel, but this can easily be extended 
with

specific defconfig to build in boota command or whatever else is required.

> 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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldef__;JSUl!!GF_29dbcQIUBPA!kJhWFr5ZO_UWn2oD_I9pDfnn64pZXw1ZBtASsxS9AZwbG65093ZydtlVPy6baPy4oeF957GBNA$
>> 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&amp;data=02%7C01%7Cpeng.fan%40nxp.com%7C950d9c0a
>> dc514927ce8b08d8180ea4ef%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
>> 0%7C0%7C637285798460563914&amp;sdata=fMrI%2FQotknCsXV0amC4BFl
>> 1Hg4vPw3zOMVdAVim2Wcs%3D&amp;reserved=0 .
>> com%2Fandr2000%2Fu-boot%2Ftree%2Fpvblock_upstream_v1&amp;data=0
>> 2%7C01%7Cpeng.fan%40nxp.com%7C407d8af24a36483fbdce08d81805ed88
>>>> %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637285761021
>> 975
>> 164&amp;sdata=5vWfBbLScICXPZWU%2BU3b7DyONcgxT8iICsxrwUbORZY%
>>>> 3D&amp;reserved=0
>>>>
>>>> [2]
>>>>
>> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldef__;JSUl!!GF_29dbcQIUBPA!kJhWFr5ZO_UWn2oD_I9pDfnn64pZXw1ZBtASsxS9AZwbG65093ZydtlVPy6baPy4oeF957GBNA$
>> 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&amp;data=02%7C01%7Cpeng.fan%40nxp.com%7C950d9c0a
>> dc514927ce8b08d8180ea4ef%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
>> 0%7C0%7C637285798460563914&amp;sdata=fMrI%2FQotknCsXV0amC4BFl
>> 1Hg4vPw3zOMVdAVim2Wcs%3D&amp;reserved=0 .
>> com%2Fxen-troops%2Fu-boot%2Fpull%2F2&amp;data=02%7C01%7Cpeng.fa
>> n%40nxp.com%7C407d8af24a36483fbdce08d81805ed88%7C686ea1d3bc2b4
>> c6fa92cd99c5c301635%7C0%7C0%7C637285761021975164&amp;sdata=%2
>> FmXheEvKssLjjaFKsHBBbqh%2B72jH3uQnE7cpN0J3k8I%3D&amp;reserved=0

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.