From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"leif.lindholm@linaro.org" <leif.lindholm@linaro.org>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"julien.grall@citrix.com" <julien.grall@citrix.com>,
"freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>,
"matt.fleming@intel.com" <matt.fleming@intel.com>,
"christoffer.dall@linaro.org" <christoffer.dall@linaro.org>,
"jbeulich@suse.com" <jbeulich@suse.com>,
"peter.huangpeng@huawei.com" <peter.huangpeng@huawei.com>,
"stefano.stabellini@eu.citrix.com"
<stefano.stabellini@eu.citrix.com>,
"shannon.zhao@linaro.org" <shannon.zhao@linaro.org>
Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters
Date: Thu, 10 Sep 2015 11:19:51 +0100 [thread overview]
Message-ID: <alpine.DEB.2.02.1509101116580.2672@kaball.uk.xensource.com> (raw)
In-Reply-To: <20150910095208.GA29293@leverpostej>
On Thu, 10 Sep 2015, Mark Rutland wrote:
> Hi,
>
> I'm not necessarily opposed to the renaming, but I think that this is
> the least important thing to standardize for this to work.
>
> On Thu, Sep 10, 2015 at 09:41:56AM +0100, Shannon Zhao wrote:
> > From: Shannon Zhao <shannon.zhao@linaro.org>
> >
> > These EFI stub parameters are used to internal communication between EFI
> > stub and Linux kernel and EFI stub creates these parameters. But for Xen
> > on ARM when booting with UEFI, Xen will create a minimal DT providing
> > these parameters for Dom0 and Dom0 is not only Linux kernel, but also
> > other OS (such as FreeBSD) which will be used in the future.
>
> Currently the Linux EFI stub and kernel have a symbiotic relationship,
> because they're intimately coupled and we don't have kexec (yet) on EFI
> platforms to loosen that coupling.
>
> If an agent other than the (kernel-specific) stub is going to provide
> this to the kernel, then we need more specified than just the property
> names.
>
> That at least includes the following:
>
> * The state of boot services (we currently have the EFI stub call
> ExitBootServices(), and I believe this is crucial to the plan for
> kexec).
>
> * The state of the address map (we currently have the EFI stub call
> SetVirtualAddressMap()).
>
> * The virtual address range(s) that SetVirtualAddressMap() may map
> elements to (this logic is currently in the EFI stub, and this matches
> the expectations of the kernel that it is tied to).
>
> > So here we plan to standardize the names by dropping the prefix
> > "linux," and make them common to other OS. Also this will not break
> > the compatibility since these parameters are used to internal
> > communication between EFI stub and kernel.
>
> For the moment this is true, but will not be once we have kexec, so
> there's a dependency (or anti-dependency) there.
>
> > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> > ---
> > Look at [1] for the discussion about this in Xen ML. The purpose of this
> > patch is to standardize the names to make Linux ARM kernel work on Xen
> > with UEFI. Also it hopes other OS(e.g. FreeBSD), which will be used as
> > Dom0 on Xen, could support this mechanism as well.
> >
> > [1]http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg02250.html
>
> Per this post, it looks like to pass a DTB to the kernel Xen already
> needs to know it's a Linux kernel...
>
> I wasn't aware that there was a common standard for arm(64) kernels
> other than a PE/COFF EFI application.
>
> Does Xen not talk to EFI itself and/or give the kernel a virtual EFI
> interface?
Xen talks to EFI itself but the interface provided to dom0 is somewhat
different: there are no BootServices (Xen calls ExitBootServices before
running the kernel), and the RuntimeServices go via hypercalls (see
drivers/xen/efi.c).
next prev parent reply other threads:[~2015-09-10 10:21 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-10 8:41 Shannon Zhao
2015-09-10 9:52 ` Mark Rutland
2015-09-10 10:19 ` Stefano Stabellini [this message]
2015-09-10 11:24 ` Mark Rutland
2015-09-10 11:37 ` Stefano Stabellini
2015-09-10 12:15 ` Mark Rutland
2015-09-10 12:58 ` [Xen-devel] " Ian Campbell
2015-09-10 13:08 ` Jan Beulich
2015-09-10 13:30 ` Ian Campbell
2015-09-10 13:52 ` Stefano Stabellini
2015-09-10 14:13 ` Leif Lindholm
2015-09-10 14:49 ` Mark Rutland
2015-09-10 16:10 ` Stefano Stabellini
2015-09-10 16:23 ` Mark Rutland
2015-09-11 12:46 ` Daniel Kiper
2015-09-11 13:14 ` Stefano Stabellini
2015-09-11 13:30 ` Ard Biesheuvel
2015-09-11 15:45 ` Daniel Kiper
2015-09-14 8:42 ` Shannon Zhao
2015-09-14 9:09 ` Ard Biesheuvel
2015-09-14 9:31 ` Shannon Zhao
2015-09-14 9:36 ` Ard Biesheuvel
2015-09-14 10:39 ` [Xen-devel] " Jan Beulich
2015-09-14 11:16 ` Ard Biesheuvel
2015-09-14 11:34 ` Jan Beulich
2015-09-11 16:33 ` Mark Rutland
2015-09-11 16:25 ` Mark Rutland
2015-09-12 11:36 ` Daniel Kiper
2015-09-14 9:25 ` Mark Rutland
2015-09-14 9:47 ` Stefano Stabellini
2015-09-14 12:19 ` Daniel Kiper
2015-09-11 11:00 ` Ian Campbell
2015-09-10 12:55 ` Jan Beulich
2015-09-10 14:53 ` Mark Rutland
2015-09-10 15:06 ` Jan Beulich
2015-09-11 16:36 ` Mark Rutland
2015-09-10 11:32 ` Andrew Turner
2015-09-10 11:48 ` Julien Grall
2015-09-10 12:05 ` Roger Pau Monné
2015-09-10 12:53 ` [Xen-devel] " Julien Grall
2015-09-17 11:43 ` Shannon Zhao
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=alpine.DEB.2.02.1509101116580.2672@kaball.uk.xensource.com \
--to=stefano.stabellini@eu.citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=ard.biesheuvel@linaro.org \
--cc=christoffer.dall@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=freebsd-arm@freebsd.org \
--cc=jbeulich@suse.com \
--cc=julien.grall@citrix.com \
--cc=leif.lindholm@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=matt.fleming@intel.com \
--cc=peter.huangpeng@huawei.com \
--cc=shannon.zhao@linaro.org \
--cc=xen-devel@lists.xen.org \
--cc=zhaoshenglong@huawei.com \
/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
all inboxes | Powered by JetHome®