xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Peng Fan <peng.fan@nxp.com>
To: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>
Cc: Anastasiia Lukianenko <Anastasiia_Lukianenko@epam.com>,
	Juergen Gross <jgross@suse.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 07:07:28 +0000	[thread overview]
Message-ID: <DB6PR0402MB27601E1DDED18CDBF3D6A18188950@DB6PR0402MB2760.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <a122102d-c023-0379-5d2c-b7b08d262844@epam.com>

> 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.

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%2Fgithub.
> com%2Fandr2000%2Fu-boot%2Ftree%2Fpvblock_upstream_v1&amp;data=0
> 2%7C01%7Cpeng.fan%40nxp.com%7C407d8af24a36483fbdce08d81805ed88
> %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637285761021975
> 164&amp;sdata=5vWfBbLScICXPZWU%2BU3b7DyONcgxT8iICsxrwUbORZY%
> 3D&amp;reserved=0
> 
> [2]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> 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

  reply	other threads:[~2020-06-24  7:08 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-31 22:05 UEFI support in ARM DomUs Roman Shaposhnik
2020-05-31 22:24 ` Julien Grall
2020-06-01  4:11   ` Roman Shaposhnik
2020-06-01 16:12     ` Stefano Stabellini
2020-06-02 22:50       ` Roman Shaposhnik
2020-06-04 16:58         ` George Dunlap
2020-06-03 10:16     ` Julien Grall
2020-06-04  1:57 ` Peng Fan
2020-06-04 15:26   ` Oleksandr Andrushchenko
2020-06-04 15:31     ` Stefano Stabellini
2020-06-04 16:50       ` Roman Shaposhnik
2020-06-15  1:58       ` Peng Fan
2020-06-18  5:22       ` Oleksandr Andrushchenko
2020-06-18 14:50         ` Julien Grall
2020-06-18 22:00           ` Stefano Stabellini
2020-06-18 22:49             ` Julien Grall
2020-06-19 12:32               ` Oleksandr Andrushchenko
2020-06-19 12:47                 ` Julien Grall
2020-06-19 12:51                   ` Oleksandr Andrushchenko
2020-06-19 12:59                     ` Julien Grall
2020-06-19 13:06                       ` Oleksandr Andrushchenko
2020-06-19 13:15                         ` Julien Grall
2020-06-19 13:29                           ` Oleksandr Andrushchenko
2020-06-22 13:56                             ` Oleksandr Andrushchenko
2020-06-22 14:23                               ` Julien Grall
2020-06-19 13:16                         ` Peng Fan
2020-06-19 13:31                           ` Oleksandr Andrushchenko
2020-06-19 20:02               ` Stefano Stabellini
2020-06-22 14:04                 ` Oleksandr Andrushchenko
2020-06-22 14:27                   ` Julien Grall
2020-06-22 14:33                     ` Oleksandr Andrushchenko
2020-06-22 17:49                       ` Julien Grall
2020-06-23  1:20                         ` Stefano Stabellini
2020-06-23  5:31                           ` Oleksandr Andrushchenko
2020-06-24  6:14                             ` Oleksandr Andrushchenko
2020-06-24  7:07                               ` Peng Fan [this message]
2020-06-24  7:17                                 ` Oleksandr Andrushchenko
2020-06-24  7:26                                   ` Peng Fan
2020-06-24  7:38                                     ` Oleksandr Andrushchenko
2020-06-24 17:05                               ` Stefano Stabellini
2020-06-24 19:31                                 ` Oleksandr Andrushchenko
2020-06-24 19:47                                   ` Stefano Stabellini
2020-06-19  7:04           ` Oleksandr Andrushchenko
2020-06-04 15:38     ` Julien Grall
2020-06-04 16:27       ` Stefano Stabellini
2020-06-04 16:34         ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB6PR0402MB27601E1DDED18CDBF3D6A18188950@DB6PR0402MB2760.eurprd04.prod.outlook.com \
    --to=peng.fan@nxp.com \
    --cc=Anastasiia_Lukianenko@epam.com \
    --cc=Bertrand.Marquis@arm.com \
    --cc=Oleksandr_Andrushchenko@epam.com \
    --cc=andr2000@gmail.com \
    --cc=jgross@suse.com \
    --cc=julien.grall.oss@gmail.com \
    --cc=julien@xen.org \
    --cc=malus.brandywine@gmail.com \
    --cc=roman@zededa.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).