Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1222046 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Shannon Zhao <zhaoshenglong@huawei.com> - 2015-09-10 11:00 +0200
    Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-10 12:00 +0200
      Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-09-10 12:30 +0200
        Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-10 13:30 +0200
          Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-09-10 13:50 +0200
            Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-10 14:20 +0200
              Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of  EFI stub parameters Ian Campbell <ian.campbell@citrix.com> - 2015-09-10 15:00 +0200
                Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names  of EFI stub parameters "Jan Beulich" <JBeulich@suse.com> - 2015-09-10 15:10 +0200
                  Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of  EFI stub parameters Ian Campbell <ian.campbell@citrix.com> - 2015-09-10 15:40 +0200
              Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-09-10 16:00 +0200
                Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Leif Lindholm <leif.lindholm@linaro.org> - 2015-09-10 16:20 +0200
                Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-10 16:50 +0200
                  Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-09-10 18:20 +0200
                    Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-10 18:30 +0200
                      Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Daniel Kiper <daniel.kiper@oracle.com> - 2015-09-11 14:50 +0200
                        Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-09-11 15:20 +0200
                          Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-11 15:40 +0200
                            Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Daniel Kiper <daniel.kiper@oracle.com> - 2015-09-11 17:50 +0200
                              Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Shannon Zhao <zhaoshenglong@huawei.com> - 2015-09-14 11:00 +0200
                                Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-14 11:10 +0200
                                  Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Shannon Zhao <zhaoshenglong@huawei.com> - 2015-09-14 11:40 +0200
                                    Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-14 11:40 +0200
                                      Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names  of EFI stub parameters "Jan Beulich" <JBeulich@suse.com> - 2015-09-14 12:40 +0200
                                        Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI  stub parameters Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-14 13:20 +0200
                                          Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names  of EFI stub parameters "Jan Beulich" <JBeulich@suse.com> - 2015-09-14 13:40 +0200
                            Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-11 18:40 +0200
                        Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-11 18:30 +0200
                          Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Daniel Kiper <daniel.kiper@oracle.com> - 2015-09-12 13:50 +0200
                            Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-14 11:30 +0200
                              Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-09-14 11:50 +0200
                              Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Daniel Kiper <daniel.kiper@oracle.com> - 2015-09-14 14:30 +0200
                    Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Ian Campbell <ian.campbell@citrix.com> - 2015-09-11 13:10 +0200
            Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters "Jan Beulich" <JBeulich@suse.com> - 2015-09-10 15:00 +0200
              Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-10 17:00 +0200
                Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters "Jan Beulich" <JBeulich@suse.com> - 2015-09-10 17:10 +0200
                  Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-11 18:40 +0200
    Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Andrew Turner <andrew@fubar.geek.nz> - 2015-09-10 13:50 +0200
      Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Julien Grall <julien.grall@citrix.com> - 2015-09-10 13:50 +0200
        Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Roger Pau Monné <roger.pau@citrix.com> - 2015-09-10 14:10 +0200
          Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of  EFI stub parameters Julien Grall <julien.grall@citrix.com> - 2015-09-10 15:00 +0200
    Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Shannon Zhao <zhaoshenglong@huawei.com> - 2015-09-17 14:00 +0200

Page 1 of 3  [1] 2 3  Next page →

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

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

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

 Documentation/arm/uefi.txt         | 10 +++++-----
 drivers/firmware/efi/efi.c         | 10 +++++-----
 drivers/firmware/efi/libstub/fdt.c | 10 +++++-----
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
index d60030a..8c83243 100644
--- a/Documentation/arm/uefi.txt
+++ b/Documentation/arm/uefi.txt
@@ -45,18 +45,18 @@ following parameters:
 ________________________________________________________________________________
 Name                      | Size   | Description
 ================================================================================
-linux,uefi-system-table   | 64-bit | Physical address of the UEFI System Table.
+uefi-system-table         | 64-bit | Physical address of the UEFI System Table.
 --------------------------------------------------------------------------------
-linux,uefi-mmap-start     | 64-bit | Physical address of the UEFI memory map,
+uefi-mmap-start           | 64-bit | Physical address of the UEFI memory map,
                           |        | populated by the UEFI GetMemoryMap() call.
 --------------------------------------------------------------------------------
-linux,uefi-mmap-size      | 32-bit | Size in bytes of the UEFI memory map
+uefi-mmap-size            | 32-bit | Size in bytes of the UEFI memory map
                           |        | pointed to in previous entry.
 --------------------------------------------------------------------------------
-linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI
+uefi-mmap-desc-size       | 32-bit | Size in bytes of each entry in the UEFI
                           |        | memory map.
 --------------------------------------------------------------------------------
-linux,uefi-mmap-desc-ver  | 32-bit | Version of the mmap descriptor format.
+uefi-mmap-desc-ver        | 32-bit | Version of the mmap descriptor format.
 --------------------------------------------------------------------------------
 linux,uefi-stub-kern-ver  | string | Copy of linux_banner from build.
 --------------------------------------------------------------------------------
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index d6144e3..3878715 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -481,11 +481,11 @@ static __initdata struct {
 	int offset;
 	int size;
 } dt_params[] = {
-	UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
-	UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
-	UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
-	UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
-	UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
+	UEFI_PARAM("System Table", "uefi-system-table", system_table),
+	UEFI_PARAM("MemMap Address", "uefi-mmap-start", mmap),
+	UEFI_PARAM("MemMap Size", "uefi-mmap-size", mmap_size),
+	UEFI_PARAM("MemMap Desc. Size", "uefi-mmap-desc-size", desc_size),
+	UEFI_PARAM("MemMap Desc. Version", "uefi-mmap-desc-ver", desc_ver)
 };
 
 struct param_info {
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index ef5d764..e94589a 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -118,31 +118,31 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
 	/* Add FDT entries for EFI runtime services in chosen node. */
 	node = fdt_subnode_offset(fdt, 0, "chosen");
 	fdt_val64 = cpu_to_fdt64((u64)(unsigned long)sys_table);
-	status = fdt_setprop(fdt, node, "linux,uefi-system-table",
+	status = fdt_setprop(fdt, node, "uefi-system-table",
 			     &fdt_val64, sizeof(fdt_val64));
 	if (status)
 		goto fdt_set_fail;
 
 	fdt_val64 = cpu_to_fdt64((u64)(unsigned long)memory_map);
-	status = fdt_setprop(fdt, node, "linux,uefi-mmap-start",
+	status = fdt_setprop(fdt, node, "uefi-mmap-start",
 			     &fdt_val64,  sizeof(fdt_val64));
 	if (status)
 		goto fdt_set_fail;
 
 	fdt_val32 = cpu_to_fdt32(map_size);
-	status = fdt_setprop(fdt, node, "linux,uefi-mmap-size",
+	status = fdt_setprop(fdt, node, "uefi-mmap-size",
 			     &fdt_val32,  sizeof(fdt_val32));
 	if (status)
 		goto fdt_set_fail;
 
 	fdt_val32 = cpu_to_fdt32(desc_size);
-	status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-size",
+	status = fdt_setprop(fdt, node, "uefi-mmap-desc-size",
 			     &fdt_val32, sizeof(fdt_val32));
 	if (status)
 		goto fdt_set_fail;
 
 	fdt_val32 = cpu_to_fdt32(desc_ver);
-	status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-ver",
+	status = fdt_setprop(fdt, node, "uefi-mmap-desc-ver",
 			     &fdt_val32, sizeof(fdt_val32));
 	if (status)
 		goto fdt_set_fail;
-- 
2.0.4


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1222072 — Re: [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 <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?

Thanks,
Mark.

>  Documentation/arm/uefi.txt         | 10 +++++-----
>  drivers/firmware/efi/efi.c         | 10 +++++-----
>  drivers/firmware/efi/libstub/fdt.c | 10 +++++-----
>  3 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
> index d60030a..8c83243 100644
> --- a/Documentation/arm/uefi.txt
> +++ b/Documentation/arm/uefi.txt
> @@ -45,18 +45,18 @@ following parameters:
>  ________________________________________________________________________________
>  Name                      | Size   | Description
>  ================================================================================
> -linux,uefi-system-table   | 64-bit | Physical address of the UEFI System Table.
> +uefi-system-table         | 64-bit | Physical address of the UEFI System Table.
>  --------------------------------------------------------------------------------
> -linux,uefi-mmap-start     | 64-bit | Physical address of the UEFI memory map,
> +uefi-mmap-start           | 64-bit | Physical address of the UEFI memory map,
>                            |        | populated by the UEFI GetMemoryMap() call.
>  --------------------------------------------------------------------------------
> -linux,uefi-mmap-size      | 32-bit | Size in bytes of the UEFI memory map
> +uefi-mmap-size            | 32-bit | Size in bytes of the UEFI memory map
>                            |        | pointed to in previous entry.
>  --------------------------------------------------------------------------------
> -linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI
> +uefi-mmap-desc-size       | 32-bit | Size in bytes of each entry in the UEFI
>                            |        | memory map.
>  --------------------------------------------------------------------------------
> -linux,uefi-mmap-desc-ver  | 32-bit | Version of the mmap descriptor format.
> +uefi-mmap-desc-ver        | 32-bit | Version of the mmap descriptor format.
>  --------------------------------------------------------------------------------
>  linux,uefi-stub-kern-ver  | string | Copy of linux_banner from build.
>  --------------------------------------------------------------------------------
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index d6144e3..3878715 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -481,11 +481,11 @@ static __initdata struct {
>  	int offset;
>  	int size;
>  } dt_params[] = {
> -	UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
> -	UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
> -	UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
> -	UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
> -	UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
> +	UEFI_PARAM("System Table", "uefi-system-table", system_table),
> +	UEFI_PARAM("MemMap Address", "uefi-mmap-start", mmap),
> +	UEFI_PARAM("MemMap Size", "uefi-mmap-size", mmap_size),
> +	UEFI_PARAM("MemMap Desc. Size", "uefi-mmap-desc-size", desc_size),
> +	UEFI_PARAM("MemMap Desc. Version", "uefi-mmap-desc-ver", desc_ver)
>  };
>  
>  struct param_info {
> diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
> index ef5d764..e94589a 100644
> --- a/drivers/firmware/efi/libstub/fdt.c
> +++ b/drivers/firmware/efi/libstub/fdt.c
> @@ -118,31 +118,31 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
>  	/* Add FDT entries for EFI runtime services in chosen node. */
>  	node = fdt_subnode_offset(fdt, 0, "chosen");
>  	fdt_val64 = cpu_to_fdt64((u64)(unsigned long)sys_table);
> -	status = fdt_setprop(fdt, node, "linux,uefi-system-table",
> +	status = fdt_setprop(fdt, node, "uefi-system-table",
>  			     &fdt_val64, sizeof(fdt_val64));
>  	if (status)
>  		goto fdt_set_fail;
>  
>  	fdt_val64 = cpu_to_fdt64((u64)(unsigned long)memory_map);
> -	status = fdt_setprop(fdt, node, "linux,uefi-mmap-start",
> +	status = fdt_setprop(fdt, node, "uefi-mmap-start",
>  			     &fdt_val64,  sizeof(fdt_val64));
>  	if (status)
>  		goto fdt_set_fail;
>  
>  	fdt_val32 = cpu_to_fdt32(map_size);
> -	status = fdt_setprop(fdt, node, "linux,uefi-mmap-size",
> +	status = fdt_setprop(fdt, node, "uefi-mmap-size",
>  			     &fdt_val32,  sizeof(fdt_val32));
>  	if (status)
>  		goto fdt_set_fail;
>  
>  	fdt_val32 = cpu_to_fdt32(desc_size);
> -	status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-size",
> +	status = fdt_setprop(fdt, node, "uefi-mmap-desc-size",
>  			     &fdt_val32, sizeof(fdt_val32));
>  	if (status)
>  		goto fdt_set_fail;
>  
>  	fdt_val32 = cpu_to_fdt32(desc_ver);
> -	status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-ver",
> +	status = fdt_setprop(fdt, node, "uefi-mmap-desc-ver",
>  			     &fdt_val32, sizeof(fdt_val32));
>  	if (status)
>  		goto fdt_set_fail;
> -- 
> 2.0.4
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222098 — Re: [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 <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).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222132 — Re: [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 hypercalls (see
> drivers/xen/efi.c).

That's somewhat hideous; a non Xen-aware OS wouild presumably die if
trying to use any runtime services the normal way? I'm not keen on
describing things that the OS cannot use.

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 virtual EFI memory map and
tables?

That would keep things sane for any guest, allow for easy addition of
EFI features, and you could even enter the usual EFI entry point,
simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest
to make things sane for itself...

Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222135 — Re: [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
> > running the kernel), and the RuntimeServices go via hypercalls (see
> > drivers/xen/efi.c).
> 
> That's somewhat hideous; a non Xen-aware OS wouild presumably die if
> trying to use any runtime services the normal way? I'm not keen on
> describing things that the OS cannot use.
 
I agree that is somewhat hideous, but a non-Xen aware OS traditionally
has never been able to even boot as Dom0. On ARM it can, but it still
wouldn't be very useful (one couldn't use it to start other guests).


> 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 virtual EFI memory map and
> tables?
> 
> That would keep things sane for any guest, allow for easy addition of
> EFI features, and you could even enter the usual EFI entry point,
> simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest
> to make things sane for itself...

That's the way it was done on x86 and now we have common code both in
Linux (drivers/xen/efi.c) and Xen (xen/common/efi) which implement this
scheme.  Switching to a different solution for ARM, would mean diverging
with x86, which is not nice, or reimplementing the x86 solution too,
which is expensive.

BTW I think that the idea you proposed was actually considered at the
time and deemed hard to implement, if I recall correctly.


In any case this should be separate from the shim ABI discussion.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222156 — Re: [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
> > > different: there are no BootServices (Xen calls ExitBootServices before
> > > running the kernel), and the RuntimeServices go via hypercalls (see
> > > drivers/xen/efi.c).
> > 
> > That's somewhat hideous; a non Xen-aware OS wouild presumably die if
> > trying to use any runtime services the normal way? I'm not keen on
> > describing things that the OS cannot use.
>  
> I agree that is somewhat hideous, but a non-Xen aware OS traditionally
> has never been able to even boot as Dom0. On ARM it can, but it still
> wouldn't be very useful (one couldn't use it to start other guests).

Sure, but it feels odd to provide the usual information in this manner
if it cannot be used. If you require Xen-specific code to make things
work, I would imagine this information could be dciscovered in a
Xen-specific manner.

> > 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 virtual EFI memory map and
> > tables?
> > 
> > That would keep things sane for any guest, allow for easy addition of
> > EFI features, and you could even enter the usual EFI entry point,
> > simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest
> > to make things sane for itself...
> 
> That's the way it was done on x86 and now we have common code both in
> Linux (drivers/xen/efi.c) and Xen (xen/common/efi) which implement this
> scheme.

This code is not currently used on arm. It might live in a location
where it may be shared, but that doesn't mean that it's common code yet.

> Switching to a different solution for ARM, would mean diverging
> with x86, which is not nice, or reimplementing the x86 solution too,
> which is expensive.
> 
> BTW I think that the idea you proposed was actually considered at the
> time and deemed hard to implement, if I recall correctly.

I appreciate that divergence is painful. We already diverge in other
respects (e.g. lack of PV page tables) because things that used to be
the case on x86 never applied to ARM.

It would be interesting to see why that was the case for x86, and
whether that applies to ARM.

> 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 considered together.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222174 — 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 considered together.

Taking a step back, the reason for using the EFI stub parameters is only
(AFAIK) in order to be able to locate the ACPI RDSP (the root table
pointer), which as it happens is normally passed via one of the EFI
firmware tables.

If there was a way to achieve that goal (i.e. another way to find the RSDP)
without opening the can of UEFI worms then we could consider that opiton
too.

a way != the legacy x86 thing of scanning low memory of the signature, of
course.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

>>> On 10.09.15 at 14:58, <ian.campbell@citrix.com> 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 insist on a particular approach, but I think
>> that they need to be considered together.
> 
> Taking a step back, the reason for using the EFI stub parameters is only
> (AFAIK) in order to be able to locate the ACPI RDSP (the root table
> pointer), which as it happens is normally passed via one of the EFI
> firmware tables.
> 
> If there was a way to achieve that goal (i.e. another way to find the RSDP)
> without opening the can of UEFI worms then we could consider that opiton
> too.
> 
> a way != the legacy x86 thing of scanning low memory of the signature, of
> course.

But even x86 doesn't do that (other than as a fallback) on EFI. The
configuration table is available to Dom0 (via XENPF_firmware_info:
XEN_FW_EFI_INFO:XEN_FW_EFI_CONFIG_TABLE).

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222201 — 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, <ian.campbell@citrix.com> 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 insist on a particular approach, but I think
> > > that they need to be considered together.
> > 
> > Taking a step back, the reason for using the EFI stub parameters is
> > only
> > (AFAIK) in order to be able to locate the ACPI RDSP (the root table
> > pointer), which as it happens is normally passed via one of the EFI
> > firmware tables.
> > 
> > If there was a way to achieve that goal (i.e. another way to find the
> > RSDP)
> > without opening the can of UEFI worms then we could consider that
> > opiton
> > too.
> > 
> > a way != the legacy x86 thing of scanning low memory of the signature,
> > of
> > course.
> 
> But even x86 doesn't do that (other than as a fallback) on EFI.

Indeed, I was referring legacy (non-EFI) mode.

>  The
> configuration table is available to Dom0 (via XENPF_firmware_info:
> XEN_FW_EFI_INFO:XEN_FW_EFI_CONFIG_TABLE).

Under ARM we find out we are running under Xen from the ACPI tables, so
there is a chicken and egg situation there.

Not insoluble I'm sure, if we want to go down this route.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222213 — Re: [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 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
> > > > different: there are no BootServices (Xen calls ExitBootServices before
> > > > running the kernel), and the RuntimeServices go via hypercalls (see
> > > > drivers/xen/efi.c).
> > > 
> > > That's somewhat hideous; a non Xen-aware OS wouild presumably die if
> > > trying to use any runtime services the normal way? I'm not keen on
> > > describing things that the OS cannot use.
> >  
> > I agree that is somewhat hideous, but a non-Xen aware OS traditionally
> > has never been able to even boot as Dom0. On ARM it can, but it still
> > wouldn't be very useful (one couldn't use it to start other guests).
> 
> Sure, but it feels odd to provide the usual information in this manner
> if it cannot be used. If you require Xen-specific code to make things
> work, I would imagine this information could be dciscovered in a
> Xen-specific manner.

We need ACPI (or Device Tree) to find that Xen is available on the
platform, so we cannot use Xen-specific code to get the ACPI tables.


> > > 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 virtual EFI memory map and
> > > tables?
> > > 
> > > That would keep things sane for any guest, allow for easy addition of
> > > EFI features, and you could even enter the usual EFI entry point,
> > > simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest
> > > to make things sane for itself...
> > 
> > That's the way it was done on x86 and now we have common code both in
> > Linux (drivers/xen/efi.c) and Xen (xen/common/efi) which implement this
> > scheme.
> 
> This code is not currently used on arm. It might live in a location
> where it may be shared, but that doesn't mean that it's common code yet.

Yeah, but that was clearly the intention.


> > Switching to a different solution for ARM, would mean diverging
> > with x86, which is not nice, or reimplementing the x86 solution too,
> > which is expensive.
> > 
> > BTW I think that the idea you proposed was actually considered at the
> > time and deemed hard to implement, if I recall correctly.
> 
> I appreciate that divergence is painful. We already diverge in other
> respects (e.g. lack of PV page tables) because things that used to be
> the case on x86 never applied to ARM.
> 
> It would be interesting to see why that was the case for x86, and
> whether that applies to ARM.

I have been a big advocate of doing things differently, and more
cleanly, on ARM, but in this case the code is already non-arch specific.
We are not talking about pagetables, which of course cannot be reused
as-is even if we wanted to.

For once, I think we should follow the x86 way, for convenience and for
the reasons brought up by Jan.


> > 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 considered together.

Let's suppose Xen didn't expose any RuntimeServices at all, would that
make it easier to discuss about the EFI stub parameters?  In the grant
scheme of things, they are not that important, as Ian wrote what is
important is how to pass the RSDP.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222230 — Re: [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
> > that they need to be considered together.
> 
> Let's suppose Xen didn't expose any RuntimeServices at all, would that
> make it easier to discuss about the EFI stub parameters?

Possibly :)

> In the grant
> scheme of things, they are not that important, as Ian wrote what is
> important is how to pass the RSDP.

So, we have discussed in the past having the ability to get at
configuration tables when UEFI is not available. Say, for example,
that we wanted SMBIOS support on a platform with U-Boot firmware.

Since all that is needed then is a UEFI System Table with a pointer to
a configuration table array, this should be fairly straightforward to
implement statically. The other parameters would not be necessary.

It would however require minor changes to the arm64 kernel UEFI support.

/
    Leif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222242 — Re: [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 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).
> > > > 
> > > > That's somewhat hideous; a non Xen-aware OS wouild presumably die if
> > > > trying to use any runtime services the normal way? I'm not keen on
> > > > describing things that the OS cannot use.
> > >  
> > > I agree that is somewhat hideous, but a non-Xen aware OS traditionally
> > > has never been able to even boot as Dom0. On ARM it can, but it still
> > > wouldn't be very useful (one couldn't use it to start other guests).
> > 
> > Sure, but it feels odd to provide the usual information in this manner
> > if it cannot be used. If you require Xen-specific code to make things
> > work, I would imagine this information could be dciscovered in a
> > Xen-specific manner.
> 
> We need ACPI (or Device Tree) to find that Xen is available on the
> platform, so we cannot use Xen-specific code to get the ACPI tables.

I don't understand. The proposition already involves passing a custom DT
to the OS, implying that Xen knows how to boot that OS, and how to pass
it a DTB.

Consider:

A) In the DT-only case, we go:

   DT -> Discover Xen -> Xen-specific stuff


B) The proposition is that un the ACPI case we go:

   DT -> EFI tables -> ACPI tables -> Discover Xen -> Xen-specific stuff -> override EFI/ACPI stuff
         \-----------------------/
          (be really cautious here)


C) When you could go:

   DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery


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)


E) Partially-generic option:
   EFI -> EFI application -> Xen detected by registered GUID -> Xen-specific EFI bootloader stuff -> OS in Xen-specific configuration


> > > 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 considered together.
> 
> Let's suppose Xen didn't expose any RuntimeServices at all, would that
> make it easier to discuss about the EFI stub parameters?

It would simply the protocol specific to Xen, certainly.

> In the grant scheme of things, they are not that important, as Ian
> wrote what is important is how to pass the RSDP.

Unfortunately we're still going to have to care about this eventually,
even if for something like kexec. So we still need to spec out the state
of things if this is going to be truly generic.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222277 — Re: [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 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).
> > > > > 
> > > > > That's somewhat hideous; a non Xen-aware OS wouild presumably die if
> > > > > trying to use any runtime services the normal way? I'm not keen on
> > > > > describing things that the OS cannot use.
> > > >  
> > > > I agree that is somewhat hideous, but a non-Xen aware OS traditionally
> > > > has never been able to even boot as Dom0. On ARM it can, but it still
> > > > wouldn't be very useful (one couldn't use it to start other guests).
> > > 
> > > Sure, but it feels odd to provide the usual information in this manner
> > > if it cannot be used. If you require Xen-specific code to make things
> > > work, I would imagine this information could be dciscovered in a
> > > Xen-specific manner.
> > 
> > We need ACPI (or Device Tree) to find that Xen is available on the
> > platform, so we cannot use Xen-specific code to get the ACPI tables.
> 
> I don't understand. The proposition already involves passing a custom DT
> to the OS, implying that Xen knows how to boot that OS, and how to pass
> it a DTB.
> 
> Consider:
> 
> A) In the DT-only case, we go:
> 
>    DT -> Discover Xen -> Xen-specific stuff
> 
> 
> B) The proposition is that un the ACPI case we go:
> 
>    DT -> EFI tables -> ACPI tables -> Discover Xen -> Xen-specific stuff -> override EFI/ACPI stuff
>          \-----------------------/
>           (be really cautious here)

Well, yes. To be pedantic "override" here would just be the different
delivery method for RuntimeServices. I guess it still counts.


> 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()?

If not, we could just go for this. A lot of complexity would go away.


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


> 
> E) Partially-generic option:
>    EFI -> EFI application -> Xen detected by registered GUID -> Xen-specific EFI bootloader stuff -> OS in Xen-specific configuration
> 
> 
> > > > 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 considered together.
> > 
> > Let's suppose Xen didn't expose any RuntimeServices at all, would that
> > make it easier to discuss about the EFI stub parameters?
> 
> It would simply the protocol specific to Xen, certainly.
> 
> > In the grant scheme of things, they are not that important, as Ian
> > wrote what is important is how to pass the RSDP.
> 
> Unfortunately we're still going to have to care about this eventually,
> even if for something like kexec. So we still need to spec out the state
> of things if this is going to be truly generic.
 
Fair enough. My position is that if we restrict this to RuntimeServices,
it might be possible, but I still prefer C).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222284 — Re: [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 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?

> > E) Partially-generic option:
> >    EFI -> EFI application -> Xen detected by registered GUID -> Xen-specific EFI bootloader stuff -> OS in Xen-specific configuration
> > 
> > 
> > > > > 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 considered together.
> > > 
> > > Let's suppose Xen didn't expose any RuntimeServices at all, would that
> > > make it easier to discuss about the EFI stub parameters?
> > 
> > It would simply the protocol specific to Xen, certainly.
> > 
> > > In the grant scheme of things, they are not that important, as Ian
> > > wrote what is important is how to pass the RSDP.
> > 
> > Unfortunately we're still going to have to care about this eventually,
> > even if for something like kexec. So we still need to spec out the state
> > of things if this is going to be truly generic.
>  
> Fair enough. My position is that if we restrict this to RuntimeServices,
> it might be possible, but I still prefer C).

Regardless of what we do we still need a well-defined state here, which
brings us back to the initial problem eventually.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222822 — Re: [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) 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?

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222836 — Re: [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 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222848

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222921 — Re: [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
> <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)

Taking into account above I think that you have most of the code in place.
Please take a look at linux/arch/x86/xen/efi.c, linux/drivers/acpi/osl.c
and linux/drivers/xen/efi.c (maybe somewhere else). In general you should
create ARM version of xen_efi_init() (x86 version you can find in
linux/drivers/xen/efi.c; it is very simple thing), maybe add some
code in a few places and voila.

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223946

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
>> <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)
> 
> Taking into account above I think that you have most of the code in place.
> Please take a look at linux/arch/x86/xen/efi.c, linux/drivers/acpi/osl.c
> and linux/drivers/xen/efi.c (maybe somewhere else). In general you should
> create ARM version of xen_efi_init() (x86 version you can find in
> linux/drivers/xen/efi.c; it is very simple thing), maybe add some
> code in a few places and voila.
> 

It only needs to apply following patch to fix a bug in Linux kernel when
mapping EFI_MEMORY_RUNTIME memory.

Author: Shannon Zhao <shannon.zhao@linaro.org>
Date:   Thu Aug 20 14:54:58 2015 +0800

    arm64/efi: Fix a bug when no EFI_MEMORY_RUNTIME memory found

    Currently if the attribute type of all the EFI Memory Descriptors are
    not EFI_MEMORY_RUNTIME, efi_virtmap_init will return true. But at this
    case, it expect false as there are no EFI memory for RUNTIME. Fix it by
    introducing a status to show whether it finds EFI_MEMORY_RUNTIME.

    Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>

diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index e8ca6ea..bad7f87 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -233,6 +233,7 @@ void __init efi_init(void)
 static bool __init efi_virtmap_init(void)
 {
        efi_memory_desc_t *md;
+       bool status = false;

        for_each_efi_memory_desc(&memmap, md) {
                u64 paddr, npages, size;
@@ -264,8 +265,11 @@ static bool __init efi_virtmap_init(void)
                        prot = PAGE_KERNEL;

                create_pgd_mapping(&efi_mm, paddr, md->virt_addr, size,
prot);
+               status = true;
        }
-       return true;
+       if (status)
+               return true;
+       return false;
 }

-- 
Shannon

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223955

On 14 September 2015 at 10:42, Shannon Zhao <zhaoshenglong@huawei.com> 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 regions?

The absence of such regions is allowed by the spec, so
efi_virtmap_init() is correct imo to return success.

If you are trying to work around the issue where Xen does not expose
any Runtime Services regions, there is simply no way to do that and be
still UEFI compliant. I have suggested before that we should perhaps
tolerate this anyway, by considering the case where the EFI System
Table has a NULL runtime services pointer. But rigging
efi_virtmap_init() like this is really not the way to achieve that.

-- 
Ard.


> Author: Shannon Zhao <shannon.zhao@linaro.org>
> Date:   Thu Aug 20 14:54:58 2015 +0800
>
>     arm64/efi: Fix a bug when no EFI_MEMORY_RUNTIME memory found
>
>     Currently if the attribute type of all the EFI Memory Descriptors are
>     not EFI_MEMORY_RUNTIME, efi_virtmap_init will return true. But at this
>     case, it expect false as there are no EFI memory for RUNTIME. Fix it by
>     introducing a status to show whether it finds EFI_MEMORY_RUNTIME.
>
>     Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
>
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index e8ca6ea..bad7f87 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -233,6 +233,7 @@ void __init efi_init(void)
>  static bool __init efi_virtmap_init(void)
>  {
>         efi_memory_desc_t *md;
> +       bool status = false;
>
>         for_each_efi_memory_desc(&memmap, md) {
>                 u64 paddr, npages, size;
> @@ -264,8 +265,11 @@ static bool __init efi_virtmap_init(void)
>                         prot = PAGE_KERNEL;
>
>                 create_pgd_mapping(&efi_mm, paddr, md->virt_addr, size,
> prot);
> +               status = true;
>         }
> -       return true;
> +       if (status)
> +               return true;
> +       return false;
>  }
>
> --
> Shannon
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel

csiph-web