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

RE: UEFI support in ARM DomUs


  • To: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>
  • From: Peng Fan <peng.fan@xxxxxxx>
  • Date: Wed, 24 Jun 2020 07:26:15 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.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=XMMv61XXOQWfosc8Ey6sbPGilo1JimUvb19FuUx/t/Y=; b=goKMsCEV8kLlXLUoUzkJyMvgoAbGltBIQnrTP4clSQfXVB96zzzixAnYqhIrY4BHECs8dVs1xE1gYV6Kp6iwxLyudk24uAOUGHOj2QwkDPGsNfQEjdgG01KnYuZ+MlIPX6TKml8xL3U3+HwrbAk3rdqxII68XFYMZucZlWzrx6SYxzGiHefT2SPiaQR+lmgKvstYiFxDoZyOcuJBxv+FsPnVhZg7PtD030m3osfV9H1WSIV/1+7Dm8JRY1o9eYcKALodd+KVItO5KXiDp//pKUihJryXnABUI0GSyYumXBgpCSO+YpbzLR9ffv1QJepOpQq3NYubFdutE0iWoCR7TQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KaP83evpfiFrhQ7YndWhFzmexrdhzr/n3zFy5hL1wwczdRtI6AbzCT92Y4twMfhBwasc2kL95dXtHWiS6+iN8P7/2Vi+Wyjkuo3pYd0incrDn20qsA4+EpsWk7uW9qGLAQz2wI6VIqnWWF+SFWALRMNIJew9Eyp5eEaofpbF45SkEO4chfoQrvKdux6aOm6bs+uStjCDw+7Mvs8SZI4EL5SPLYPX4meMAJolfR0fFcxWYE9+PIVysmFLLy6HOXY7dur58qX9MmYaiX98VE1I5B3jpH4AFhbGqRXIYw/s/6I/P9iRyhsvoDXs2gDwFvS0ocjdYTC6Jr6HMLifDS9zqQ==
  • Authentication-results: epam.com; dkim=none (message not signed) header.d=none;epam.com; dmarc=none action=none header.from=nxp.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:26:28 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWN5exllox/cqJUUS0HFcLChNz8ajHt2rggADieACAAAFjAIAVVnEAgACes4CAAHgUgIAADcUAgAFjwoCABFLagIAABoCAgAABwICAADaWgIAAfiIAgABGNACAAZ5agIAADjmAgAADNoCAAAB6UA==
  • Thread-topic: 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&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://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&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®.