[PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Shannon Zhao
From: Shannon Zhao 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

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Mark Rutland
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 > > These EFI stub parameters are used to internal

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Julien Grall
On 10/09/15 12:32, Andrew Turner wrote: > On Thu, 10 Sep 2015 16:41:56 +0800 > Shannon Zhao wrote: > >> From: Shannon Zhao >> >> These EFI stub parameters are used to internal communication between >> EFI stub and Linux kernel and EFI stub

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Mark Rutland
On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote: > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > > 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 > > >

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Ian Campbell
On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote: > > In any case this should be separate from the shim ABI discussion. > > I disagree; I think this is very much relevant to the ABI discussion. > That's not to say that I insist on a particular approach, but I think > that they need to be

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Mark Rutland
> > 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

Re: [PATCH v2] arm64/efi: don't pad between EFI_MEMORY_RUNTIME regions

2015-09-10 Thread Mark Rutland
Hi, FWIW I gave this a spin on Seattle and Juno and saw no regressions (both are pre-2.5 EFI though). I have some concerns below. On Wed, Sep 09, 2015 at 08:06:54AM +0100, Ard Biesheuvel wrote: > The new Properties Table feature introduced in UEFIv2.5 may split > memory regions that cover

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Andrew Turner
On Thu, 10 Sep 2015 16:41:56 +0800 Shannon Zhao wrote: > From: Shannon Zhao > > 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

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Jan Beulich
>>> On 10.09.15 at 14:58, wrote: > On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote: > >> > In any case this should be separate from the shim ABI discussion. >> >> I disagree; I think this is very much relevant to the ABI discussion. >> That's not to say that I

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Jan Beulich
>>> On 10.09.15 at 13:37, wrote: > On Thu, 10 Sep 2015, Mark Rutland wrote: >> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g. >> create pages of RuntimeServicesCode that are trivial assembly shims >> doing hypercalls, and plumb these into the

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Julien Grall
On 10/09/15 13:05, Roger Pau Monné wrote: > El 10/09/15 a les 13.48, Julien Grall ha escrit: >> On 10/09/15 12:32, Andrew Turner wrote: >>> On Thu, 10 Sep 2015 16:41:56 +0800 >>> Shannon Zhao wrote: >>> From: Shannon Zhao These

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Ian Campbell
On Thu, 2015-09-10 at 07:08 -0600, Jan Beulich wrote: > > > > On 10.09.15 at 14:58, wrote: > > On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote: > > > > > > In any case this should be separate from the shim ABI discussion. > > > > > > I disagree; I think this is

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Roger Pau Monné
El 10/09/15 a les 13.48, Julien Grall ha escrit: > On 10/09/15 12:32, Andrew Turner wrote: >> On Thu, 10 Sep 2015 16:41:56 +0800 >> Shannon Zhao wrote: >> >>> From: Shannon Zhao >>> >>> These EFI stub parameters are used to internal

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Stefano Stabellini
On Thu, 10 Sep 2015, Mark Rutland wrote: > On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote: > > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI > > > > > interface? > > > > > > > > Xen talks to EFI itself

Re: [PATCH v2] arm64/efi: don't pad between EFI_MEMORY_RUNTIME regions

2015-09-10 Thread Mark Rutland
> >> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c > >> index e8ca6eaedd02..13671a9cf016 100644 > >> --- a/arch/arm64/kernel/efi.c > >> +++ b/arch/arm64/kernel/efi.c > >> @@ -258,7 +258,8 @@ static bool __init efi_virtmap_init(void) > >>*/ > >> if

Re: [PATCH v2] arm64/efi: don't pad between EFI_MEMORY_RUNTIME regions

2015-09-10 Thread Ard Biesheuvel
On 10 September 2015 at 16:04, Mark Rutland wrote: >> >> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c >> >> index e8ca6eaedd02..13671a9cf016 100644 >> >> --- a/arch/arm64/kernel/efi.c >> >> +++ b/arch/arm64/kernel/efi.c >> >> @@ -258,7 +258,8 @@ static bool

[PATCH v3] arm64/efi: don't pad between EFI_MEMORY_RUNTIME regions

2015-09-10 Thread Ard Biesheuvel
The new Properties Table feature introduced in UEFIv2.5 may split memory regions that cover PE/COFF memory images into separate code and data regions. Since these regions only differ in the type (runtime code vs runtime data) and the permission bits, but not in the memory type attributes

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Mark Rutland
On Thu, Sep 10, 2015 at 02:52:25PM +0100, Stefano Stabellini wrote: > On Thu, 10 Sep 2015, Mark Rutland wrote: > > On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote: > > > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > > > > Does Xen not talk to EFI itself and/or give the kernel a

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Mark Rutland
On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote: > >>> On 10.09.15 at 13:37, wrote: > > On Thu, 10 Sep 2015, Mark Rutland wrote: > >> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g. > >> create pages of RuntimeServicesCode that are

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Leif Lindholm
On Thu, Sep 10, 2015 at 02:52:25PM +0100, Stefano Stabellini wrote: > > > In any case this should be separate from the shim ABI discussion. > > > > I disagree; I think this is very much relevant to the ABI discussion. > > That's not to say that I insist on a particular approach, but I think > >

Re: [PATCH v2] arm64/efi: don't pad between EFI_MEMORY_RUNTIME regions

2015-09-10 Thread Mark Rutland
> OK so what we could do is the following: > > 8<-- > diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c > index e8ca6eaedd02..39fa2a70a7f1 100644 > --- a/arch/arm64/kernel/efi.c > +++ b/arch/arm64/kernel/efi.c > @@ -233,6 +233,7 @@ void __init efi_init(void) >

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Jan Beulich
>>> On 10.09.15 at 16:53, wrote: > On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote: >> >>> On 10.09.15 at 13:37, wrote: >> > On Thu, 10 Sep 2015, Mark Rutland wrote: >> >> Why can't Xen give a virtual EFI interface to Dom0 /

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Mark Rutland
> > 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

Re: [PATCH v3] arm64/efi: don't pad between EFI_MEMORY_RUNTIME regions

2015-09-10 Thread Ard Biesheuvel
On 10 September 2015 at 18:08, Mark Rutland wrote: > On Thu, Sep 10, 2015 at 04:41:39PM +0100, Ard Biesheuvel wrote: >> The new Properties Table feature introduced in UEFIv2.5 may split >> memory regions that cover PE/COFF memory images into separate code >> and data

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

2015-09-10 Thread Stefano Stabellini
On Thu, 10 Sep 2015, Mark Rutland wrote: > On Thu, Sep 10, 2015 at 02:52:25PM +0100, Stefano Stabellini wrote: > > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote: > > > > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > > > > > Does

Re: [PATCH V2 2/2] ras: acpi / apei: generate trace event for unrecognized CPER section

2015-09-10 Thread Borislav Petkov
On Tue, Sep 08, 2015 at 02:29:21PM -0700, Jonathan (Zhixiong) Zhang wrote: > /* > + * Raw Events Report > + * > + * This event is generated when hardware detected a hardware > + * error event, which may be of non-standard section as defined > + * in UEFI spec appendix "Common Platform Error

Re: [PATCH V2 1/2] efi: print unrecognized CPER section

2015-09-10 Thread Borislav Petkov
On Tue, Sep 08, 2015 at 02:29:20PM -0700, Jonathan (Zhixiong) Zhang wrote: > From: "Jonathan (Zhixiong) Zhang" > > UEFI spec allows for non-standard section in Common Platform Error > Record. This is defined in section N.2.3 of UEFI version 2.5. > > Currently if the CPER