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
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
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
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
> > >
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
> > 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
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
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
>>> 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
>>> 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
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
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
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
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
> >> 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
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
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
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
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
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
> >
> 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)
>
>>> 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 /
> > 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
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
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
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
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
27 matches
Mail list logo