Re: [PATCH v7 00/10] xen: Add EFI support
On 30/06/14 18:52, Daniel Kiper wrote: Hey, This patch series adds EFI support for Xen dom0 guests. It is based on Jan Beulich and Tang Liang work. I was trying to take into account all previous comments, however, if I missed something sorry for that. What's changed in this version? David -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/10] xen: Add EFI support
On Tue, Jul 01, 2014 at 02:13:10PM +0100, David Vrabel wrote: On 30/06/14 18:52, Daniel Kiper wrote: Hey, This patch series adds EFI support for Xen dom0 guests. It is based on Jan Beulich and Tang Liang work. I was trying to take into account all previous comments, however, if I missed something sorry for that. What's changed in this version? I have added arch/ia64: Define early_memunmap() patch, moved xen_efi_probe() declaration to include/xen/xen-ops.h as Stefano asked, added yours Reviewed-by to Xen stuff and did more tests. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] efi: preserve NEON registers on UEFI services calls
On Thu, 26 Jun, at 12:09:04PM, Ard Biesheuvel wrote: The current UEFI implementation for arm64 fails to preserve/restore the contents of the NEON register file, which may result in data corruption, especially now that those contents are lazily restored for user processes. This series proposes to fix this by wrapping all runtime services calls, and adding kernel_neon_begin()/kernel_neon_end() pairs to the wrappers. The first patch moves the existing x86 versions of those wrappers to generic code, so that the second patch can easily enable them by supplying a definition for efi_call_virt and adding a call to efi_native_runtime_setup(). Changes since v1: - rename runtime.c - runtime-wrappers.c - make build depend on new Kconfig symbol EFI_RUNTIME_WRAPPERS to fix ia64 breakage - remove default #defines for efi_call_virt()/__efi_call_virt(), they are not needed anymore now that it is built conditionally - add references to applicable UEFI/AAPCS spec sections Ard Biesheuvel (2): efi/x86: move UEFI Runtime Services wrappers to generic code efi/arm64: preserve FP/SIMD registers on UEFI runtime services calls Thanks Ard. These patches look OK to me, and I've now pulled them into my 'next' branch. It'd be nice if we could get some ACKs from other people since this is an ABI issue. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] efi/x86: move UEFI Runtime Services wrappers to generic code
On Thu, 26 Jun, at 12:09:05PM, Ard Biesheuvel wrote: In order for other archs (such as arm64) to be able to reuse the virtual mode function call wrappers, move them to drivers/firmware/efi/runtime-wrappers.c. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org [...] @@ -54,6 +54,13 @@ config EFI_PARAMS_FROM_FDT the EFI runtime support gets system table address, memory map address, and other parameters from the device tree. +config EFI_RUNTIME_WRAPPERS + bool + help + Selected by the arch if it needs to wrap UEFI Runtime Services calls, + in which case it needs to provide #definitions of efi_call_virt and + __efi_call_virt in asm/efi.h + endmenu Actually, could we drop this help text? That may seem like a backwards step, but I have concerns that we'll fail to keep this help text in sync with the code. Furthermore, by providing help text that kinda says, casual users need the help text to understand when to enable this feature. Clearly that's not what this Kconfig symbol is for. Most of the other guard Kconfig symbols don't provide this kind of text, and I think there's good reason to follow suit. What do you think? -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] efi/x86: move UEFI Runtime Services wrappers to generic code
On 1 July 2014 15:30, Matt Fleming m...@console-pimps.org wrote: On Thu, 26 Jun, at 12:09:05PM, Ard Biesheuvel wrote: In order for other archs (such as arm64) to be able to reuse the virtual mode function call wrappers, move them to drivers/firmware/efi/runtime-wrappers.c. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org [...] @@ -54,6 +54,13 @@ config EFI_PARAMS_FROM_FDT the EFI runtime support gets system table address, memory map address, and other parameters from the device tree. +config EFI_RUNTIME_WRAPPERS + bool + help + Selected by the arch if it needs to wrap UEFI Runtime Services calls, + in which case it needs to provide #definitions of efi_call_virt and + __efi_call_virt in asm/efi.h + endmenu Actually, could we drop this help text? That may seem like a backwards step, but I have concerns that we'll fail to keep this help text in sync with the code. Furthermore, by providing help text that kinda says, casual users need the help text to understand when to enable this feature. Clearly that's not what this Kconfig symbol is for. Most of the other guard Kconfig symbols don't provide this kind of text, and I think there's good reason to follow suit. What do you think? I agree, but I kind of followed the example of the Kconfig symbols in the vicinity. So sure, rip it out. Or would you like me to do a v(n+1)? -- Ard. -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] efi: preserve NEON registers on UEFI services calls
On 1 July 2014 15:26, Matt Fleming m...@console-pimps.org wrote: On Thu, 26 Jun, at 12:09:04PM, Ard Biesheuvel wrote: The current UEFI implementation for arm64 fails to preserve/restore the contents of the NEON register file, which may result in data corruption, especially now that those contents are lazily restored for user processes. This series proposes to fix this by wrapping all runtime services calls, and adding kernel_neon_begin()/kernel_neon_end() pairs to the wrappers. The first patch moves the existing x86 versions of those wrappers to generic code, so that the second patch can easily enable them by supplying a definition for efi_call_virt and adding a call to efi_native_runtime_setup(). Changes since v1: - rename runtime.c - runtime-wrappers.c - make build depend on new Kconfig symbol EFI_RUNTIME_WRAPPERS to fix ia64 breakage - remove default #defines for efi_call_virt()/__efi_call_virt(), they are not needed anymore now that it is built conditionally - add references to applicable UEFI/AAPCS spec sections Ard Biesheuvel (2): efi/x86: move UEFI Runtime Services wrappers to generic code efi/arm64: preserve FP/SIMD registers on UEFI runtime services calls Thanks Ard. These patches look OK to me, and I've now pulled them into my 'next' branch. It'd be nice if we could get some ACKs from other people since this is an ABI issue. Yes, they have been awfully quiet, haven't they? At least Roy has volunteered to get involved in the USWG to get the spec clarified. @Leif, Catalin, Olivier: care to chime in? -- Ard. -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] efi/x86: move UEFI Runtime Services wrappers to generic code
On Tue, 01 Jul, at 03:35:09PM, Ard Biesheuvel wrote: I agree, but I kind of followed the example of the Kconfig symbols in the vicinity. So sure, rip it out. Or would you like me to do a v(n+1)? Thanks. Nah, no need for another version, I'ved fixed this up in 'next', but please do check the commits to make sure nothing untoward has occurred. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/5] efi: efistub: refactor stub components
On 1 July 2014 17:11, Matt Fleming m...@console-pimps.org wrote:
On Thu, 26 Jun, at 04:23:36PM, Ard Biesheuvel wrote:
In order to move from the #include ../../../x.c anti-pattern used by
both the x86 and arm64 versions of the stub to a static library linked into
either the kernel proper (arm64) or a separate boot executable (x86), there
is some prepatory work required.
This patch does the following:
- move forward declarations of functions shared between the arch specific and
the generic parts of the stub to include/linux/efi.h
- move forward declarations of functions shared between various .c files of
the
generic stub code to a new local header file called efistub.h
- add #includes to all .c files which were formerly relying on the #includor
to
include the correct header files
- remove all static modifiers from functions which will need to be externally
visible once we move to a static library
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
[...]
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 0ceb816bdfc2..3a64f2f85821 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1163,4 +1163,46 @@ static inline void
efi_runtime_map_setup(void *map, int nr_entries, u32 desc_size) {}
#endif
+/* prototypes shared between arch specific and generic stub code */
+
+#define pr_efi(sys_table, msg) efi_printk(sys_table, EFI stub: msg)
+#define pr_efi_err(sys_table, msg) efi_printk(sys_table, EFI stub: ERROR:
msg)
+
+void efi_printk(efi_system_table_t *sys_table_arg, char *str);
+
+void efi_free(efi_system_table_t *sys_table_arg, unsigned long size,
+ unsigned long addr);
+
+char *efi_convert_cmdline(efi_system_table_t *sys_table_arg,
+ efi_loaded_image_t *image, int *cmd_line_len);
+
We've been very good so far at not splattering include/linux/efi.h with
any of the EFI boot stub prototypes, and it would be awesome if we
didn't have to start now.
Is there any way we could avoid doing this? Arguably everything should
be in the new efistub.h, no?
There are bits that are shared between code under arch/xxx and
drivers/firmware/efi, and what those bits are is different between the
archs. I used asm/efi.h just for convenience, but perhaps we could
add asm/efistub.h for each arch, and #include it in both efistub.h
under drivers/firmware/efi and the stub bits that live under arch/xxx?
Then any other users of asm/efi.h won't have to see it.
--
Ard.
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] efistub: convert into static library
On Thu, 26 Jun, at 04:23:32PM, Ard Biesheuvel wrote: This is v2 of the series to change the #include ../../../../xxx.c pattern into a static library linked into either the kernel (arm64) or a separate boot decompressor (x86, ARM). Changes since v1: - added patch #1 to change EFI_ERROR, it is not a result code defined by UEFI so it should only be returned by get_dram_base() and efi_entry() - added a section to libstub Makefile to clean CFLAGS of stack protecter and other options that are inappropriate for the stub - rebased onto the UEFI Runtime Services NEON patches (re)posted earlier today Ard Biesheuvel (5): efi/arm64: avoid EFI_ERROR as a generic return code efi/x86: efistub: move shared dependencies to asm/efi.h efi/arm64: efistub: move shared dependencies to asm/efi.h efi: efistub: refactor stub components efi: efistub: convert into static library Thanks Ard. I've picked these up. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] efistub: convert into static library
On Tue, 01 Jul, at 08:55:20PM, Ard Biesheuvel wrote: OK, thanks. One tiny snag that I would like to fix up once we have some Acks to add: I just noticed that i removed the 'static' from handle_kernel_image()'s definition from arm64 in 4/5, but removed it from the forward declaration in 5/5, which likely breaks bisect for arm64 if you happen to end up right in the middle. Good catch. I rebase 'next' pretty feely, so just remind me at some point in the future and we can fix this up. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] kexec: Support kexec/kdump on EFI systems
On Thu, 26 Jun, at 04:33:44PM, Vivek Goyal wrote:
This patch does two thigns. It passes EFI run time mappings to second
kernel in bootparams efi_info. Second kernel parse this info and create
new mappings in second kernel. That means mappings in first and second
kernel will be same. This paves the way to enable EFI in kexec kernel.
This patch also prepares and passes EFI setup data through bootparams.
This contains bunch of information about various tables and their
addresses.
These information gathering and passing has been written along the lines
of what current kexec-tools is doing to make kexec work with UEFI.
Signed-off-by: Vivek Goyal vgo...@redhat.com
CC: linux-efi@vger.kernel.org
---
arch/x86/kernel/kexec-bzimage64.c | 146
++---
drivers/firmware/efi/runtime-map.c | 21 ++
include/linux/efi.h| 19 +
3 files changed, 174 insertions(+), 12 deletions(-)
[...]
diff --git a/drivers/firmware/efi/runtime-map.c
b/drivers/firmware/efi/runtime-map.c
index 97cdd16..40f2213 100644
--- a/drivers/firmware/efi/runtime-map.c
+++ b/drivers/firmware/efi/runtime-map.c
@@ -138,6 +138,27 @@ add_sysfs_runtime_map_entry(struct kobject *kobj, int nr)
return entry;
}
+int get_efi_runtime_map_size(void)
+{
+ return nr_efi_runtime_map * efi_memdesc_size;
+}
+
+int get_efi_runtime_map_desc_size(void)
+{
+ return efi_memdesc_size;
+}
+
+int efi_runtime_map_copy(void *buf, size_t bufsz)
+{
+ size_t sz = get_efi_runtime_map_size();
+
+ if (sz bufsz)
+ sz = bufsz;
+
+ memcpy(buf, efi_runtime_map, sz);
+ return 0;
+}
Could we prefix these with efi_, e.g. efi_get_runtime_map_size() ?
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/15] kexec-bzimage: Change EFI helper function names
Matt suggested to change helper function names newly introduced functions
and prefix these with efi_.
Signed-off-by: Vivek Goyal vgo...@redhat.com
CC: Matt Fleming m...@console-pimps.org
CC: linux-efi@vger.kernel.org
---
arch/x86/kernel/kexec-bzimage64.c |4 ++--
drivers/firmware/efi/runtime-map.c |6 +++---
include/linux/efi.h|4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
Index: linux-2.6/include/linux/efi.h
===
--- linux-2.6.orig/include/linux/efi.h 2014-07-01 14:05:54.197071710 -0400
+++ linux-2.6/include/linux/efi.h 2014-07-01 15:54:21.019754754 -0400
@@ -1151,8 +1151,8 @@ int efivars_sysfs_init(void);
#ifdef CONFIG_EFI_RUNTIME_MAP
int efi_runtime_map_init(struct kobject *);
void efi_runtime_map_setup(void *, int, u32);
-int get_efi_runtime_map_size(void);
-int get_efi_runtime_map_desc_size(void);
+int efi_get_runtime_map_size(void);
+int efi_get_runtime_map_desc_size(void);
int efi_runtime_map_copy(void *buf, size_t bufsz);
#else
static inline int efi_runtime_map_init(struct kobject *kobj)
Index: linux-2.6/drivers/firmware/efi/runtime-map.c
===
--- linux-2.6.orig/drivers/firmware/efi/runtime-map.c 2014-07-01
14:05:54.196071711 -0400
+++ linux-2.6/drivers/firmware/efi/runtime-map.c2014-07-01
15:55:47.990759859 -0400
@@ -138,19 +138,19 @@ add_sysfs_runtime_map_entry(struct kobje
return entry;
}
-int get_efi_runtime_map_size(void)
+int efi_get_runtime_map_size(void)
{
return nr_efi_runtime_map * efi_memdesc_size;
}
-int get_efi_runtime_map_desc_size(void)
+int efi_get_runtime_map_desc_size(void)
{
return efi_memdesc_size;
}
int efi_runtime_map_copy(void *buf, size_t bufsz)
{
- size_t sz = get_efi_runtime_map_size();
+ size_t sz = efi_get_runtime_map_size();
if (sz bufsz)
sz = bufsz;
Index: linux-2.6/arch/x86/kernel/kexec-bzimage64.c
===
--- linux-2.6.orig/arch/x86/kernel/kexec-bzimage64.c2014-07-01
15:52:22.285747785 -0400
+++ linux-2.6/arch/x86/kernel/kexec-bzimage64.c 2014-07-01 15:56:31.071762387
-0400
@@ -181,7 +181,7 @@ setup_efi_state(struct boot_params *para
ei-efi_systab_hi = current_ei-efi_systab_hi;
ei-efi_memdesc_version = current_ei-efi_memdesc_version;
- ei-efi_memdesc_size = get_efi_runtime_map_desc_size();
+ ei-efi_memdesc_size = efi_get_runtime_map_desc_size();
setup_efi_info_memmap(params, params_load_addr, efi_map_offset,
efi_map_sz);
@@ -397,7 +397,7 @@ void *bzImage64_load(struct kimage *imag
* have to create separate segment for each. Keeps things
* little bit simple
*/
- efi_map_sz = get_efi_runtime_map_size();
+ efi_map_sz = efi_get_runtime_map_size();
efi_map_sz = ALIGN(efi_map_sz, 16);
params_cmdline_sz = sizeof(struct boot_params) + cmdline_len +
MAX_ELFCOREHDR_STR_LEN;
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] kexec: Support kexec/kdump on EFI systems
On Tue, 1 Jul 2014 20:46:05 +0100 Matt Fleming m...@console-pimps.org wrote:
+int get_efi_runtime_map_size(void)
+{
+ return nr_efi_runtime_map * efi_memdesc_size;
+}
+
+int get_efi_runtime_map_desc_size(void)
+{
+ return efi_memdesc_size;
+}
+
+int efi_runtime_map_copy(void *buf, size_t bufsz)
+{
+ size_t sz = get_efi_runtime_map_size();
+
+ if (sz bufsz)
+ sz = bufsz;
+
+ memcpy(buf, efi_runtime_map, sz);
+ return 0;
+}
Could we prefix these with efi_, e.g. efi_get_runtime_map_size() ?
This?
From: Andrew Morton a...@linux-foundation.org
Subject: kexec-support-kexec-kdump-on-efi-systems-fix
s/get_efi/efi_get/g, per Matt
Cc: Vivek Goyal vgo...@redhat.com
Cc: Matt Fleming m...@console-pimps.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
arch/x86/kernel/kexec-bzimage64.c |4 ++--
drivers/firmware/efi/runtime-map.c |6 +++---
include/linux/efi.h|8
3 files changed, 9 insertions(+), 9 deletions(-)
diff -puN
arch/x86/kernel/kexec-bzimage64.c~kexec-support-kexec-kdump-on-efi-systems-fix
arch/x86/kernel/kexec-bzimage64.c
---
a/arch/x86/kernel/kexec-bzimage64.c~kexec-support-kexec-kdump-on-efi-systems-fix
+++ a/arch/x86/kernel/kexec-bzimage64.c
@@ -181,7 +181,7 @@ setup_efi_state(struct boot_params *para
ei-efi_systab_hi = current_ei-efi_systab_hi;
ei-efi_memdesc_version = current_ei-efi_memdesc_version;
- ei-efi_memdesc_size = get_efi_runtime_map_desc_size();
+ ei-efi_memdesc_size = efi_get_runtime_map_desc_size();
setup_efi_info_memmap(params, params_load_addr, efi_map_offset,
efi_map_sz);
@@ -397,7 +397,7 @@ void *bzImage64_load(struct kimage *imag
* have to create separate segment for each. Keeps things
* little bit simple
*/
- efi_map_sz = get_efi_runtime_map_size();
+ efi_map_sz = efi_get_runtime_map_size();
efi_map_sz = ALIGN(efi_map_sz, 16);
params_cmdline_sz = sizeof(struct boot_params) + cmdline_len +
MAX_ELFCOREHDR_STR_LEN;
diff -puN
drivers/firmware/efi/runtime-map.c~kexec-support-kexec-kdump-on-efi-systems-fix
drivers/firmware/efi/runtime-map.c
---
a/drivers/firmware/efi/runtime-map.c~kexec-support-kexec-kdump-on-efi-systems-fix
+++ a/drivers/firmware/efi/runtime-map.c
@@ -138,19 +138,19 @@ add_sysfs_runtime_map_entry(struct kobje
return entry;
}
-int get_efi_runtime_map_size(void)
+int efi_get_runtime_map_size(void)
{
return nr_efi_runtime_map * efi_memdesc_size;
}
-int get_efi_runtime_map_desc_size(void)
+int efi_get_runtime_map_desc_size(void)
{
return efi_memdesc_size;
}
int efi_runtime_map_copy(void *buf, size_t bufsz)
{
- size_t sz = get_efi_runtime_map_size();
+ size_t sz = efi_get_runtime_map_size();
if (sz bufsz)
sz = bufsz;
diff -puN include/linux/efi.h~kexec-support-kexec-kdump-on-efi-systems-fix
include/linux/efi.h
--- a/include/linux/efi.h~kexec-support-kexec-kdump-on-efi-systems-fix
+++ a/include/linux/efi.h
@@ -1151,8 +1151,8 @@ int efivars_sysfs_init(void);
#ifdef CONFIG_EFI_RUNTIME_MAP
int efi_runtime_map_init(struct kobject *);
void efi_runtime_map_setup(void *, int, u32);
-int get_efi_runtime_map_size(void);
-int get_efi_runtime_map_desc_size(void);
+int efi_get_runtime_map_size(void);
+int efi_get_runtime_map_desc_size(void);
int efi_runtime_map_copy(void *buf, size_t bufsz);
#else
static inline int efi_runtime_map_init(struct kobject *kobj)
@@ -1163,12 +1163,12 @@ static inline int efi_runtime_map_init(s
static inline void
efi_runtime_map_setup(void *map, int nr_entries, u32 desc_size) {}
-static inline int get_efi_runtime_map_size(void)
+static inline int efi_get_runtime_map_size(void)
{
return 0;
}
-static inline int get_efi_runtime_map_desc_size(void)
+static inline int efi_get_runtime_map_desc_size(void)
{
return 0;
}
_
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] kexec: Support kexec/kdump on EFI systems
On Tue, Jul 01, 2014 at 01:14:19PM -0700, Andrew Morton wrote:
On Tue, 1 Jul 2014 20:46:05 +0100 Matt Fleming m...@console-pimps.org wrote:
+int get_efi_runtime_map_size(void)
+{
+ return nr_efi_runtime_map * efi_memdesc_size;
+}
+
+int get_efi_runtime_map_desc_size(void)
+{
+ return efi_memdesc_size;
+}
+
+int efi_runtime_map_copy(void *buf, size_t bufsz)
+{
+ size_t sz = get_efi_runtime_map_size();
+
+ if (sz bufsz)
+ sz = bufsz;
+
+ memcpy(buf, efi_runtime_map, sz);
+ return 0;
+}
Could we prefix these with efi_, e.g. efi_get_runtime_map_size() ?
This?
From: Andrew Morton a...@linux-foundation.org
Subject: kexec-support-kexec-kdump-on-efi-systems-fix
s/get_efi/efi_get/g, per Matt
Cc: Vivek Goyal vgo...@redhat.com
Cc: Matt Fleming m...@console-pimps.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
Looks good to me. Thanks Andrew.
Vivek
---
arch/x86/kernel/kexec-bzimage64.c |4 ++--
drivers/firmware/efi/runtime-map.c |6 +++---
include/linux/efi.h|8
3 files changed, 9 insertions(+), 9 deletions(-)
diff -puN
arch/x86/kernel/kexec-bzimage64.c~kexec-support-kexec-kdump-on-efi-systems-fix
arch/x86/kernel/kexec-bzimage64.c
---
a/arch/x86/kernel/kexec-bzimage64.c~kexec-support-kexec-kdump-on-efi-systems-fix
+++ a/arch/x86/kernel/kexec-bzimage64.c
@@ -181,7 +181,7 @@ setup_efi_state(struct boot_params *para
ei-efi_systab_hi = current_ei-efi_systab_hi;
ei-efi_memdesc_version = current_ei-efi_memdesc_version;
- ei-efi_memdesc_size = get_efi_runtime_map_desc_size();
+ ei-efi_memdesc_size = efi_get_runtime_map_desc_size();
setup_efi_info_memmap(params, params_load_addr, efi_map_offset,
efi_map_sz);
@@ -397,7 +397,7 @@ void *bzImage64_load(struct kimage *imag
* have to create separate segment for each. Keeps things
* little bit simple
*/
- efi_map_sz = get_efi_runtime_map_size();
+ efi_map_sz = efi_get_runtime_map_size();
efi_map_sz = ALIGN(efi_map_sz, 16);
params_cmdline_sz = sizeof(struct boot_params) + cmdline_len +
MAX_ELFCOREHDR_STR_LEN;
diff -puN
drivers/firmware/efi/runtime-map.c~kexec-support-kexec-kdump-on-efi-systems-fix
drivers/firmware/efi/runtime-map.c
---
a/drivers/firmware/efi/runtime-map.c~kexec-support-kexec-kdump-on-efi-systems-fix
+++ a/drivers/firmware/efi/runtime-map.c
@@ -138,19 +138,19 @@ add_sysfs_runtime_map_entry(struct kobje
return entry;
}
-int get_efi_runtime_map_size(void)
+int efi_get_runtime_map_size(void)
{
return nr_efi_runtime_map * efi_memdesc_size;
}
-int get_efi_runtime_map_desc_size(void)
+int efi_get_runtime_map_desc_size(void)
{
return efi_memdesc_size;
}
int efi_runtime_map_copy(void *buf, size_t bufsz)
{
- size_t sz = get_efi_runtime_map_size();
+ size_t sz = efi_get_runtime_map_size();
if (sz bufsz)
sz = bufsz;
diff -puN include/linux/efi.h~kexec-support-kexec-kdump-on-efi-systems-fix
include/linux/efi.h
--- a/include/linux/efi.h~kexec-support-kexec-kdump-on-efi-systems-fix
+++ a/include/linux/efi.h
@@ -1151,8 +1151,8 @@ int efivars_sysfs_init(void);
#ifdef CONFIG_EFI_RUNTIME_MAP
int efi_runtime_map_init(struct kobject *);
void efi_runtime_map_setup(void *, int, u32);
-int get_efi_runtime_map_size(void);
-int get_efi_runtime_map_desc_size(void);
+int efi_get_runtime_map_size(void);
+int efi_get_runtime_map_desc_size(void);
int efi_runtime_map_copy(void *buf, size_t bufsz);
#else
static inline int efi_runtime_map_init(struct kobject *kobj)
@@ -1163,12 +1163,12 @@ static inline int efi_runtime_map_init(s
static inline void
efi_runtime_map_setup(void *map, int nr_entries, u32 desc_size) {}
-static inline int get_efi_runtime_map_size(void)
+static inline int efi_get_runtime_map_size(void)
{
return 0;
}
-static inline int get_efi_runtime_map_desc_size(void)
+static inline int efi_get_runtime_map_desc_size(void)
{
return 0;
}
_
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] kexec: Support kexec/kdump on EFI systems
On Tue, 01 Jul, at 01:14:19PM, Andrew Morton wrote: This? From: Andrew Morton a...@linux-foundation.org Subject: kexec-support-kexec-kdump-on-efi-systems-fix s/get_efi/efi_get/g, per Matt Cc: Vivek Goyal vgo...@redhat.com Cc: Matt Fleming m...@console-pimps.org Signed-off-by: Andrew Morton a...@linux-foundation.org Yep, looks spot on. Thanks Andrew. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
