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

Hi, >From the comments on this patch, IIUC, we don't object to the change brought by this patch. What we didn't reach an agreement is how to support runtime service for Dom0. Right? If so, I think this patch doesn't conflict with adding support for runtime service in the future. So could we move

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

>>> On 14.09.15 at 11:36, wrote: > On 14 September 2015 at 11:31, Shannon Zhao wrote: >> My understanding is that if there are no EFI_MEMORY_RUNTIME regions, it >> means we can't use runtime services and should not set the bit >>

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

On Mon, Sep 14, 2015 at 11:43:27AM +0200, Ard Biesheuvel wrote: > On 14 September 2015 at 11:25, Mark Rutland wrote: > > On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote: > >> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote: > >> > On Fri, Sep 11,

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

On 14 September 2015 at 14:28, Daniel Kiper wrote: > On Mon, Sep 14, 2015 at 11:43:27AM +0200, Ard Biesheuvel wrote: >> On 14 September 2015 at 11:25, Mark Rutland wrote: >> > On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote: >> >> On

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

On Mon, Sep 14, 2015 at 10:25:19AM +0100, Mark Rutland wrote: > On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote: > > On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote: > > > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote: > > > > On Thu, Sep 10, 2015 at

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

On 14 September 2015 at 12:39, Jan Beulich wrote: On 14.09.15 at 11:36, wrote: >> On 14 September 2015 at 11:31, Shannon Zhao wrote: >>> My understanding is that if there are no EFI_MEMORY_RUNTIME regions, it >>> means

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

>>> On 14.09.15 at 13:16, wrote: > (I still think not using SetVirtualAddressMap() at all > would be the best approach for arm64, but unfortunately, most of my > colleagues disagree with me) Any reasons they have? I'm curious because we run x86 Xen without using this

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

On Mon, Sep 14, 2015 at 03:09:34PM +0200, Ard Biesheuvel wrote: > On 14 September 2015 at 14:28, Daniel Kiper wrote: > > On Mon, Sep 14, 2015 at 11:43:27AM +0200, Ard Biesheuvel wrote: > >> On 14 September 2015 at 11:25, Mark Rutland wrote: > >> >

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

On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote: > On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote: > > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote: > > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: > > [...] > > > > > What's

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

On 2015/9/14 17:09, Ard Biesheuvel wrote: > On 14 September 2015 at 10:42, Shannon Zhao wrote: > [..] > >> >> It only needs to apply following patch to fix a bug in Linux kernel when >> mapping EFI_MEMORY_RUNTIME memory. >> > > Could you explain why you think

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

(snip some cc's) On 14 September 2015 at 11:31, Shannon Zhao wrote: > > > On 2015/9/14 17:09, Ard Biesheuvel wrote: >> On 14 September 2015 at 10:42, Shannon Zhao wrote: >> [..] >> >>> >>> It only needs to apply following patch to fix a bug in

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

On 14 September 2015 at 11:25, Mark Rutland wrote: > On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote: >> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote: >> > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote: >> > > On Thu, Sep 10, 2015

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

On Mon, 14 Sep 2015, Mark Rutland wrote: > On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote: > > On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote: > > > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote: > > > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark

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

On 2015/9/11 23:45, Daniel Kiper wrote: > On Fri, Sep 11, 2015 at 03:30:15PM +0200, Ard Biesheuvel wrote: >> On 11 September 2015 at 15:14, Stefano Stabellini >> wrote: >>> On Fri, 11 Sep 2015, Daniel Kiper wrote: On Thu, Sep 10, 2015 at 05:23:02PM +0100,

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

On 14 September 2015 at 10:42, Shannon Zhao wrote: [..] > > It only needs to apply following patch to fix a bug in Linux kernel when > mapping EFI_MEMORY_RUNTIME memory. > Could you explain why you think efi_virtmap_init() should fail if there are no EFI_MEMORY_RUNTIME

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

On Mon, 2015-09-14 at 11:43 +0200, Ard Biesheuvel wrote: > Xen will not boot the kernel via the stub, but directly. It needs to > supply a EFI like environment so that the kernel can boot via ACPI. > There is no reason whatsoever to mock up boot services or other pieces > of UEFI functionality

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

On 14 September 2015 at 11:57, Ian Campbell wrote: > On Mon, 2015-09-14 at 11:43 +0200, Ard Biesheuvel wrote: > >> Xen will not boot the kernel via the stub, but directly. It needs to >> supply a EFI like environment so that the kernel can boot via ACPI. >> There is no

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

On Mon, 2015-09-14 at 12:02 +0200, Ard Biesheuvel wrote: > On 14 September 2015 at 11:57, Ian Campbell wrote: > > > or SetVirtualAddressMap/ConvertPointer, and > > > > These two are RTS, so in principal it could. > > > > (I'm not sure about ConvertPointer, is it useful

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

On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote: > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote: > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: [...] > > > What's troublesome with the boot services? > > > > > > What can't be simulated? > > > > How

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

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

On Fri, Sep 11, 2015 at 01:46:43PM +0100, 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

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

> 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. My understanding from the last

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

> >> Considering that the EFI support is just for Dom0, and Dom0 (at > >> the time) had to be PV anyway, it was the more natural solution to > >> expose the interface via hypercalls, the more that this allows better > >> control over what is and primarily what is not being exposed to > >> Dom0.

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

On 11 September 2015 at 15:14, Stefano Stabellini 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 ->

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

On Thu, 2015-09-10 at 17:10 +0100, Stefano Stabellini 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. There may be other options,

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

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)

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

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

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

On Fri, Sep 11, 2015 at 03:30:15PM +0200, Ard Biesheuvel wrote: > On 11 September 2015 at 15:14, Stefano Stabellini > 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

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

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: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

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

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

> > 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: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

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: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

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: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

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: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

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

>>> 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: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

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 > > different: there are no BootServices (Xen calls ExitBootServices before > >

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

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

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

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: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

>>> 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: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

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: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

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: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

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: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

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: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

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