From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
Mark Rutland <mark.rutland@arm.com>,
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>,
"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>,
"shannon.zhao@linaro.org" <shannon.zhao@linaro.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters
Date: Fri, 11 Sep 2015 15:30:15 +0200 [thread overview]
Message-ID: <CAKv+Gu9rN7_mxk0huX+34HSCC_aTWVTkUZKQMB1+9U56fRnwsA@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1509111410180.2672@kaball.uk.xensource.com>
On 11 September 2015 at 15:14, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 11 Sep 2015, Daniel Kiper wrote:
>> On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
>> > > > C) When you could go:
>> > > >
>> > > > DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery
>> > >
>> > > I take you mean discovering Xen with the usual Xen hypervisor node on
>> > > device tree. I think that C) is a good option actually. I like it. Not
>> > > sure why we didn't think about this earlier. Is there anything EFI or
>> > > ACPI which is needed before Xen support is discovered by
>> > > arch/arm64/kernel/setup.c:setup_arch -> xen_early_init()?
>> >
>> > Currently lots (including the memory map). With the stuff to support
>> > SPCR, the ACPI discovery would be moved before xen_early_init().
>> >
>> > > If not, we could just go for this. A lot of complexity would go away.
>> >
>> > I suspect this would still be fairly complex, but would at least prevent
>> > the Xen-specific EFI handling from adversely affecting the native case.
>> >
>> > > > D) If you want to be generic:
>> > > > EFI -> EFI application -> EFI tables -> ACPI tables -> Xen-specific stuff
>> > > > \------------------------------------------/
>> > > > (virtualize these, provide shims to Dom0, but handle
>> > > > everything in Xen itself)
>> > >
>> > > I think that this is good in theory but could turn out to be a lot of
>> > > work in practice. We could probably virtualize the RuntimeServices but
>> > > the BootServices are troublesome.
>> >
>> > What's troublesome with the boot services?
>> >
>> > What can't be simulated?
>>
>> How do you want to access bare metal EFI boot services from dom0 if they
>> were shutdown long time ago before loading dom0 image? What do you need
>> from EFI boot services in dom0?
>
> That's right. Trying to emulate BootServices after the real
> ExitBootServices has already been called seems like a very bad plan.
>
> I think that whatever interface we come up with, would need to be past
> ExitBootServices.
It feels like this discussion is going in circles.
When we discussed this six months ago, we already concluded that,
since UEFI is the only specified way that the presence of ACPI is
advertised on an ARM system, we need to emulate UEFI to some extent.
So we need the EFI system table to expose the UEFI configuration table
that carries the ACPI root pointer.
Since ACPI support also relies on the UEFI memory map (I think?), we
need that as well.
These two items are exactly what we pass via the UEFI DT properties,
so we should indeed promote the current de-facto binding to a proper
binding, and renaming the properties makes sense in that context.
I agree that this should also include a description of the expected
state of the firmware, i.e., that ExitBootServices() has been called,
and that the memory map has been populated with virtual address, which
have been installed using SetVirtualAddressMap() if they differ from
the physical addresses. (The current implementation on the kernel side
is perfectly capable of dealing with a 1:1 mapping).
Beyond that, there is no point in pretending to be a full UEFI
implementation, imo. Boot services are not required, nor are runtime
services (only the current EFI init code on arm needs to be modified
to deal with a NULL runtime services pointer)
--
Ard.
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
Mark Rutland <mark.rutland@arm.com>,
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>,
"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.c
Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters
Date: Fri, 11 Sep 2015 15:30:15 +0200 [thread overview]
Message-ID: <CAKv+Gu9rN7_mxk0huX+34HSCC_aTWVTkUZKQMB1+9U56fRnwsA@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1509111410180.2672@kaball.uk.xensource.com>
On 11 September 2015 at 15:14, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 11 Sep 2015, Daniel Kiper wrote:
>> On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
>> > > > C) When you could go:
>> > > >
>> > > > DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery
>> > >
>> > > I take you mean discovering Xen with the usual Xen hypervisor node on
>> > > device tree. I think that C) is a good option actually. I like it. Not
>> > > sure why we didn't think about this earlier. Is there anything EFI or
>> > > ACPI which is needed before Xen support is discovered by
>> > > arch/arm64/kernel/setup.c:setup_arch -> xen_early_init()?
>> >
>> > Currently lots (including the memory map). With the stuff to support
>> > SPCR, the ACPI discovery would be moved before xen_early_init().
>> >
>> > > If not, we could just go for this. A lot of complexity would go away.
>> >
>> > I suspect this would still be fairly complex, but would at least prevent
>> > the Xen-specific EFI handling from adversely affecting the native case.
>> >
>> > > > D) If you want to be generic:
>> > > > EFI -> EFI application -> EFI tables -> ACPI tables -> Xen-specific stuff
>> > > > \------------------------------------------/
>> > > > (virtualize these, provide shims to Dom0, but handle
>> > > > everything in Xen itself)
>> > >
>> > > I think that this is good in theory but could turn out to be a lot of
>> > > work in practice. We could probably virtualize the RuntimeServices but
>> > > the BootServices are troublesome.
>> >
>> > What's troublesome with the boot services?
>> >
>> > What can't be simulated?
>>
>> How do you want to access bare metal EFI boot services from dom0 if they
>> were shutdown long time ago before loading dom0 image? What do you need
>> from EFI boot services in dom0?
>
> That's right. Trying to emulate BootServices after the real
> ExitBootServices has already been called seems like a very bad plan.
>
> I think that whatever interface we come up with, would need to be past
> ExitBootServices.
It feels like this discussion is going in circles.
When we discussed this six months ago, we already concluded that,
since UEFI is the only specified way that the presence of ACPI is
advertised on an ARM system, we need to emulate UEFI to some extent.
So we need the EFI system table to expose the UEFI configuration table
that carries the ACPI root pointer.
Since ACPI support also relies on the UEFI memory map (I think?), we
need that as well.
These two items are exactly what we pass via the UEFI DT properties,
so we should indeed promote the current de-facto binding to a proper
binding, and renaming the properties makes sense in that context.
I agree that this should also include a description of the expected
state of the firmware, i.e., that ExitBootServices() has been called,
and that the memory map has been populated with virtual address, which
have been installed using SetVirtualAddressMap() if they differ from
the physical addresses. (The current implementation on the kernel side
is perfectly capable of dealing with a 1:1 mapping).
Beyond that, there is no point in pretending to be a full UEFI
implementation, imo. Boot services are not required, nor are runtime
services (only the current EFI init code on arm needs to be modified
to deal with a NULL runtime services pointer)
--
Ard.
WARNING: multiple messages have this Message-ID (diff)
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters
Date: Fri, 11 Sep 2015 15:30:15 +0200 [thread overview]
Message-ID: <CAKv+Gu9rN7_mxk0huX+34HSCC_aTWVTkUZKQMB1+9U56fRnwsA@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1509111410180.2672@kaball.uk.xensource.com>
On 11 September 2015 at 15:14, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 11 Sep 2015, Daniel Kiper wrote:
>> On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
>> > > > C) When you could go:
>> > > >
>> > > > DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery
>> > >
>> > > I take you mean discovering Xen with the usual Xen hypervisor node on
>> > > device tree. I think that C) is a good option actually. I like it. Not
>> > > sure why we didn't think about this earlier. Is there anything EFI or
>> > > ACPI which is needed before Xen support is discovered by
>> > > arch/arm64/kernel/setup.c:setup_arch -> xen_early_init()?
>> >
>> > Currently lots (including the memory map). With the stuff to support
>> > SPCR, the ACPI discovery would be moved before xen_early_init().
>> >
>> > > If not, we could just go for this. A lot of complexity would go away.
>> >
>> > I suspect this would still be fairly complex, but would at least prevent
>> > the Xen-specific EFI handling from adversely affecting the native case.
>> >
>> > > > D) If you want to be generic:
>> > > > EFI -> EFI application -> EFI tables -> ACPI tables -> Xen-specific stuff
>> > > > \------------------------------------------/
>> > > > (virtualize these, provide shims to Dom0, but handle
>> > > > everything in Xen itself)
>> > >
>> > > I think that this is good in theory but could turn out to be a lot of
>> > > work in practice. We could probably virtualize the RuntimeServices but
>> > > the BootServices are troublesome.
>> >
>> > What's troublesome with the boot services?
>> >
>> > What can't be simulated?
>>
>> How do you want to access bare metal EFI boot services from dom0 if they
>> were shutdown long time ago before loading dom0 image? What do you need
>> from EFI boot services in dom0?
>
> That's right. Trying to emulate BootServices after the real
> ExitBootServices has already been called seems like a very bad plan.
>
> I think that whatever interface we come up with, would need to be past
> ExitBootServices.
It feels like this discussion is going in circles.
When we discussed this six months ago, we already concluded that,
since UEFI is the only specified way that the presence of ACPI is
advertised on an ARM system, we need to emulate UEFI to some extent.
So we need the EFI system table to expose the UEFI configuration table
that carries the ACPI root pointer.
Since ACPI support also relies on the UEFI memory map (I think?), we
need that as well.
These two items are exactly what we pass via the UEFI DT properties,
so we should indeed promote the current de-facto binding to a proper
binding, and renaming the properties makes sense in that context.
I agree that this should also include a description of the expected
state of the firmware, i.e., that ExitBootServices() has been called,
and that the memory map has been populated with virtual address, which
have been installed using SetVirtualAddressMap() if they differ from
the physical addresses. (The current implementation on the kernel side
is perfectly capable of dealing with a 1:1 mapping).
Beyond that, there is no point in pretending to be a full UEFI
implementation, imo. Boot services are not required, nor are runtime
services (only the current EFI init code on arm needs to be modified
to deal with a NULL runtime services pointer)
--
Ard.
next prev parent reply other threads:[~2015-09-11 13:30 UTC|newest]
Thread overview: 182+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-10 8:41 [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Shannon Zhao
2015-09-10 8:41 ` Shannon Zhao
2015-09-10 8:41 ` Shannon Zhao
2015-09-10 9:52 ` Mark Rutland
2015-09-10 9:52 ` Mark Rutland
2015-09-10 9:52 ` Mark Rutland
2015-09-10 9:52 ` Mark Rutland
2015-09-10 10:19 ` Stefano Stabellini
2015-09-10 10:19 ` Stefano Stabellini
2015-09-10 10:19 ` Stefano Stabellini
2015-09-10 11:24 ` Mark Rutland
2015-09-10 11:24 ` Mark Rutland
2015-09-10 11:24 ` Mark Rutland
2015-09-10 11:37 ` Stefano Stabellini
2015-09-10 11:37 ` Stefano Stabellini
2015-09-10 11:37 ` Stefano Stabellini
2015-09-10 12:15 ` Mark Rutland
2015-09-10 12:15 ` Mark Rutland
2015-09-10 12:15 ` Mark Rutland
2015-09-10 12:58 ` Ian Campbell
2015-09-10 12:58 ` [Xen-devel] " Ian Campbell
2015-09-10 12:58 ` Ian Campbell
2015-09-10 12:58 ` Ian Campbell
2015-09-10 13:08 ` Jan Beulich
2015-09-10 13:08 ` [Xen-devel] " Jan Beulich
2015-09-10 13:08 ` Jan Beulich
2015-09-10 13:08 ` Jan Beulich
2015-09-10 13:30 ` Ian Campbell
2015-09-10 13:30 ` Ian Campbell
2015-09-10 13:30 ` Ian Campbell
2015-09-10 13:30 ` Ian Campbell
2015-09-10 13:52 ` Stefano Stabellini
2015-09-10 13:52 ` Stefano Stabellini
2015-09-10 13:52 ` Stefano Stabellini
2015-09-10 13:52 ` Stefano Stabellini
2015-09-10 14:13 ` Leif Lindholm
2015-09-10 14:13 ` Leif Lindholm
2015-09-10 14:13 ` Leif Lindholm
2015-09-10 14:13 ` Leif Lindholm
2015-09-10 14:49 ` Mark Rutland
2015-09-10 14:49 ` Mark Rutland
2015-09-10 14:49 ` Mark Rutland
2015-09-10 14:49 ` Mark Rutland
2015-09-10 16:10 ` Stefano Stabellini
2015-09-10 16:10 ` Stefano Stabellini
2015-09-10 16:10 ` Stefano Stabellini
2015-09-10 16:10 ` Stefano Stabellini
2015-09-10 16:23 ` Mark Rutland
2015-09-10 16:23 ` Mark Rutland
2015-09-10 16:23 ` Mark Rutland
2015-09-11 12:46 ` Daniel Kiper
2015-09-11 12:46 ` Daniel Kiper
2015-09-11 12:46 ` Daniel Kiper
2015-09-11 12:46 ` Daniel Kiper
2015-09-11 13:14 ` Stefano Stabellini
2015-09-11 13:14 ` Stefano Stabellini
2015-09-11 13:14 ` Stefano Stabellini
2015-09-11 13:14 ` Stefano Stabellini
2015-09-11 13:30 ` Ard Biesheuvel
2015-09-11 13:30 ` Ard Biesheuvel [this message]
2015-09-11 13:30 ` Ard Biesheuvel
2015-09-11 13:30 ` Ard Biesheuvel
2015-09-11 15:45 ` Daniel Kiper
2015-09-11 15:45 ` Daniel Kiper
2015-09-11 15:45 ` Daniel Kiper
2015-09-11 15:45 ` Daniel Kiper
2015-09-14 8:42 ` Shannon Zhao
2015-09-14 8:42 ` Shannon Zhao
2015-09-14 8:42 ` Shannon Zhao
2015-09-14 9:09 ` Ard Biesheuvel
2015-09-14 9:09 ` Ard Biesheuvel
2015-09-14 9:09 ` Ard Biesheuvel
2015-09-14 9:31 ` Shannon Zhao
2015-09-14 9:31 ` Shannon Zhao
2015-09-14 9:31 ` Shannon Zhao
2015-09-14 9:36 ` Ard Biesheuvel
2015-09-14 9:36 ` Ard Biesheuvel
2015-09-14 9:36 ` Ard Biesheuvel
2015-09-14 9:36 ` Ard Biesheuvel
2015-09-14 10:39 ` Jan Beulich
2015-09-14 10:39 ` [Xen-devel] " Jan Beulich
2015-09-14 10:39 ` Jan Beulich
2015-09-14 10:39 ` Jan Beulich
2015-09-14 11:16 ` Ard Biesheuvel
2015-09-14 11:16 ` Ard Biesheuvel
2015-09-14 11:16 ` Ard Biesheuvel
2015-09-14 11:34 ` Jan Beulich
2015-09-14 11:34 ` [Xen-devel] " Jan Beulich
2015-09-14 11:34 ` Jan Beulich
2015-09-14 11:34 ` Jan Beulich
2015-09-14 11:16 ` Ard Biesheuvel
2015-09-14 9:09 ` Ard Biesheuvel
2015-09-11 16:33 ` Mark Rutland
2015-09-11 16:33 ` Mark Rutland
2015-09-11 16:33 ` Mark Rutland
2015-09-11 16:33 ` Mark Rutland
2015-09-11 16:25 ` Mark Rutland
2015-09-11 16:25 ` Mark Rutland
2015-09-11 16:25 ` Mark Rutland
2015-09-12 11:36 ` Daniel Kiper
2015-09-12 11:36 ` Daniel Kiper
2015-09-12 11:36 ` Daniel Kiper
2015-09-14 9:25 ` Mark Rutland
2015-09-14 9:25 ` Mark Rutland
2015-09-14 9:25 ` Mark Rutland
2015-09-14 9:43 ` Ard Biesheuvel
2015-09-14 9:43 ` Ard Biesheuvel
2015-09-14 9:57 ` Ian Campbell
2015-09-14 12:28 ` Daniel Kiper
[not found] ` <CAKv+Gu9ER1cKvPHobq-wo7ggPesJj4OQ7=aTr24GVpubHvVqjQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-14 9:57 ` Ian Campbell
2015-09-14 9:57 ` Ian Campbell
[not found] ` <1442224673.3549.131.camel-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
2015-09-14 10:02 ` Ard Biesheuvel
2015-09-14 10:02 ` Ard Biesheuvel
[not found] ` <CAKv+Gu_Gh649EwdtodLY9Q28JhqYg8o6RShXXH1ZbxsfYRfi2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-14 10:25 ` Ian Campbell
2015-09-14 10:25 ` Ian Campbell
2015-09-14 10:25 ` Ian Campbell
2015-09-14 10:02 ` Ard Biesheuvel
2015-09-14 12:28 ` Daniel Kiper
2015-09-14 12:28 ` Daniel Kiper
2015-09-14 13:09 ` Ard Biesheuvel
[not found] ` <20150914122858.GI4530-fJNZiO034lp9pOct4yEdx/3oZC3j2Omk@public.gmane.org>
2015-09-14 13:09 ` Ard Biesheuvel
2015-09-14 13:09 ` Ard Biesheuvel
[not found] ` <CAKv+Gu_z2X=9-qgoKTS7dKLqtSUvysyu9LzZryJqcSR4X8Ss6A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-14 13:57 ` Daniel Kiper
2015-09-14 13:57 ` Daniel Kiper
2015-09-14 13:57 ` Daniel Kiper
2015-09-14 9:43 ` Ard Biesheuvel
2015-09-14 9:47 ` Stefano Stabellini
2015-09-14 9:47 ` Stefano Stabellini
2015-09-14 9:47 ` Stefano Stabellini
2015-09-14 9:47 ` Stefano Stabellini
2015-09-14 12:19 ` Daniel Kiper
2015-09-14 12:19 ` Daniel Kiper
2015-09-14 12:19 ` Daniel Kiper
2015-09-14 12:19 ` Daniel Kiper
2015-09-14 9:25 ` Mark Rutland
2015-09-12 11:36 ` Daniel Kiper
2015-09-11 16:25 ` Mark Rutland
2015-09-10 16:23 ` Mark Rutland
2015-09-11 11:00 ` Ian Campbell
2015-09-11 11:00 ` Ian Campbell
2015-09-11 11:00 ` Ian Campbell
2015-09-11 11:00 ` Ian Campbell
2015-09-10 12:15 ` Mark Rutland
2015-09-10 12:55 ` Jan Beulich
2015-09-10 12:55 ` Jan Beulich
2015-09-10 12:55 ` Jan Beulich
2015-09-10 14:53 ` Mark Rutland
2015-09-10 14:53 ` Mark Rutland
2015-09-10 14:53 ` Mark Rutland
2015-09-10 15:06 ` Jan Beulich
2015-09-10 15:06 ` Jan Beulich
2015-09-10 15:06 ` Jan Beulich
2015-09-11 16:36 ` Mark Rutland
2015-09-11 16:36 ` Mark Rutland
2015-09-11 16:36 ` Mark Rutland
2015-09-11 16:36 ` Mark Rutland
2015-09-10 15:06 ` Jan Beulich
2015-09-10 12:55 ` Jan Beulich
2015-09-10 11:37 ` Stefano Stabellini
2015-09-10 11:24 ` Mark Rutland
2015-09-10 10:19 ` Stefano Stabellini
2015-09-10 11:32 ` Andrew Turner
2015-09-10 11:32 ` Andrew Turner
2015-09-10 11:32 ` Andrew Turner
2015-09-10 11:32 ` Andrew Turner
2015-09-10 11:48 ` Julien Grall
2015-09-10 11:48 ` Julien Grall
2015-09-10 11:48 ` Julien Grall
2015-09-10 12:05 ` Roger Pau Monné
2015-09-10 12:05 ` Roger Pau Monné
2015-09-10 12:05 ` Roger Pau Monné
2015-09-10 12:53 ` Julien Grall
2015-09-10 12:53 ` [Xen-devel] " Julien Grall
2015-09-10 12:53 ` Julien Grall
2015-09-10 12:53 ` Julien Grall
2015-09-10 12:05 ` Roger Pau Monné
2015-09-10 11:48 ` Julien Grall
2015-09-17 11:43 ` Shannon Zhao
2015-09-17 11:43 ` Shannon Zhao
2015-09-17 11:43 ` Shannon Zhao
2015-09-17 11:43 ` Shannon Zhao
-- strict thread matches above, loose matches on Subject: below --
2015-09-10 8:41 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=CAKv+Gu9rN7_mxk0huX+34HSCC_aTWVTkUZKQMB1+9U56fRnwsA@mail.gmail.com \
--to=ard.biesheuvel@linaro.org \
--cc=Ian.Campbell@citrix.com \
--cc=christoffer.dall@linaro.org \
--cc=daniel.kiper@oracle.com \
--cc=devicetree@vger.kernel.org \
--cc=freebsd-arm@freebsd.org \
--cc=jbeulich@suse.com \
--cc=julien.grall@citrix.com \
--cc=konrad.wilk@oracle.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=stefano.stabellini@eu.citrix.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.