* [PATCH v5 00/14] kexec kernel efi runtime support
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
Hi,
Here is the V5 patchset for supporting kexec kernel efi runtime.
Per pervious discussion I pass the 1st kernel efi runtime mapping
via setup_data to 2nd kernel. Besides of the runtime mapping
info I also pass the fw_vendor, runtime, config table, smbios
physical address in setup_data. EFI spec mentioned fw_vendor,
runtime, config table addresses will be converted to virt address
after entering virtual mode, but we will use it as physical address
in efi_init. For smbios EFI spec did not mention about the address
updating, but during my test on a HP workstation, the bios will
convert it to Virt addr, thus pass it in setup_data as well.
For fw_vendor, runtime, config table, I export them in /sys/firmware/
efi/, smbios is already in /sys/firmware/efi/systab.
For efi runtime mapping I add a new directory /sys/firmware/efi/
runtime-map/ like below
[dave@darkstar ~]$ tree /sys/firmware/efi/runtime-map/
/sys/firmware/efi/runtime-map/
|__ 0
| |__ attribute
| |__ num_pages
| |__ phys_addr
| |__ type
| |__ virt_addr
|__ 1
[snip]
kexec-tools will assemble them as setup_data and pass to 2nd kernel.
I will send userspace patches as well.
Limitation is I only write support for x86_64, test on below machines:
Lenovo thinkpad t420
Dell inspiron 14 - 3421
HP Z420 workstation
Qemu + OVMF
The patches are based on linus tree + matt's efi master tree
Changes from v1:
add one flag in xloadflags, so kexec-tools can safely load old kernel
without efi support.
coding style fixes
function name for map phys_addr to fixed virt_addr
Add ABI documentation for sysfs files
Changes from v2:
01/09: a new patch to remove unused variables in __map_region function
catched by Toshi Kani
09/09: a new patch to export x86 boot_params to sysfs instead of use
debugfs files
Matt: reuse __map_region instead do same thing in another function.
add a wrapper function efi_map_region_fixed [02/09]
check return value of krealloc
sysfs dir name s/efi-runtime-map/runtime-map [06/09]
use desc_size in efi_runtime_map
for the xloadflags defination: +&& defined(CONFIG_KEXEC)
Greg: sysfs : one file one value for fw_vendor, runtime, tables. [05/09]
Document them in ABI testing
HPA: Document the new xloadflag
Also there's other function cleanup and improvement for error handling.
Changes from v3:
Greg: sysfs code move to use __ATTR_RO and attr_group
Boris: comments and code alignment
Added 3 new patches below
10-print-efi-runtime-memmap.patch
- 10/12: print only runtime ranges in case EFI_DEBUG printing
11-reserve-setup-data-late.patch
- fix a bug of kdump kernel, move function for reserving setup data
ranges late after parsing memmap= cmdline params because kdump kernel
will pass exact memmap late.
12-x86-kdebugfs-use-ioremap.patch
- fix a bug of x86/kernel/kdebugfs.c, use ioremap instead of __va for
low mem because __va does not work for exact memmap=
Changes from V4:
- variable efi_setup in 09/14 is changed to the physical address instead of the virtual address
because it will be not iounmapped until entering virtual mode, it's too long and could cause
leak.
- sparse warnings fixes (Matt):
Added 2 new patches to addressing sparse warnings:
01/14: x86-mm-sparse-warning-fix-for-early_memremap.patch
02/14: efi-use-early_memremap-and-early_memunmap.patch
- krealloc fixes (Boris)
- rebase on top of Linus tree + Matt's efi master tree (Boris)
- a lot of documention/spelling fixes (Boris)
- share function save_runtime_map in 1st/2nd kernel code (Matt)
- style and other fixes detail see the patch changelog themselves.
Boris: I still use the function name efi_reuse_config because it could be not only a problem for
HP workstation, also because we will later split them to another file so efi_ is acceptable for me.
The patches stay in kexec-efi-testing branch of below repo for testing:
https://github.com/daveyoung/linux.git
Dave Young (14):
x86/mm: sparse warning fix for early_memremap
efi: use early_memremap and early_memunmap
efi: remove unused variables in __map_region
efi: add a wrapper function efi_map_region_fixed
efi: reserve boot service fix
efi: cleanup efi_enter_virtual_mode function
efi: export more efi table variable to sysfs
efi: export efi runtime memory mapping to sysfs
efi: passing kexec necessary efi data via setup_data
efi: only print saved efi runtime maps instead of all memmap ranges
for kexec
x86: add xloadflags bit for efi runtime support on kexec
x86: export x86 boot_params to sysfs
x86: reserve setup_data ranges late after parsing memmap cmdline
x86: kdebugfs do not use __va for getting setup_data virt addr
Documentation/ABI/testing/sysfs-firmware-efi | 24 ++
.../ABI/testing/sysfs-firmware-efi-runtime-map | 36 ++
Documentation/ABI/testing/sysfs-kernel-boot_params | 39 +++
Documentation/x86/boot.txt | 3 +
arch/x86/boot/header.S | 9 +-
arch/x86/include/asm/efi.h | 12 +
arch/x86/include/asm/io.h | 3 +-
arch/x86/include/uapi/asm/bootparam.h | 2 +
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/kdebugfs.c | 35 +-
arch/x86/kernel/ksysfs.c | 339 ++++++++++++++++++
arch/x86/kernel/setup.c | 7 +-
arch/x86/mm/ioremap.c | 10 +-
arch/x86/platform/efi/efi.c | 378 ++++++++++++++++-----
arch/x86/platform/efi/efi_32.c | 2 +
arch/x86/platform/efi/efi_64.c | 16 +-
drivers/firmware/efi/Kconfig | 11 +
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/efi.c | 47 ++-
drivers/firmware/efi/runtime-map.c | 176 ++++++++++
include/linux/efi.h | 9 +
21 files changed, 1038 insertions(+), 122 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi
create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
create mode 100644 Documentation/ABI/testing/sysfs-kernel-boot_params
create mode 100644 arch/x86/kernel/ksysfs.c
create mode 100644 drivers/firmware/efi/runtime-map.c
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* [PATCH v5 00/14] kexec kernel efi runtime support
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bp-Gina5bIWoIWzQB+pC5nmwQ, greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
Hi,
Here is the V5 patchset for supporting kexec kernel efi runtime.
Per pervious discussion I pass the 1st kernel efi runtime mapping
via setup_data to 2nd kernel. Besides of the runtime mapping
info I also pass the fw_vendor, runtime, config table, smbios
physical address in setup_data. EFI spec mentioned fw_vendor,
runtime, config table addresses will be converted to virt address
after entering virtual mode, but we will use it as physical address
in efi_init. For smbios EFI spec did not mention about the address
updating, but during my test on a HP workstation, the bios will
convert it to Virt addr, thus pass it in setup_data as well.
For fw_vendor, runtime, config table, I export them in /sys/firmware/
efi/, smbios is already in /sys/firmware/efi/systab.
For efi runtime mapping I add a new directory /sys/firmware/efi/
runtime-map/ like below
[dave@darkstar ~]$ tree /sys/firmware/efi/runtime-map/
/sys/firmware/efi/runtime-map/
|__ 0
| |__ attribute
| |__ num_pages
| |__ phys_addr
| |__ type
| |__ virt_addr
|__ 1
[snip]
kexec-tools will assemble them as setup_data and pass to 2nd kernel.
I will send userspace patches as well.
Limitation is I only write support for x86_64, test on below machines:
Lenovo thinkpad t420
Dell inspiron 14 - 3421
HP Z420 workstation
Qemu + OVMF
The patches are based on linus tree + matt's efi master tree
Changes from v1:
add one flag in xloadflags, so kexec-tools can safely load old kernel
without efi support.
coding style fixes
function name for map phys_addr to fixed virt_addr
Add ABI documentation for sysfs files
Changes from v2:
01/09: a new patch to remove unused variables in __map_region function
catched by Toshi Kani
09/09: a new patch to export x86 boot_params to sysfs instead of use
debugfs files
Matt: reuse __map_region instead do same thing in another function.
add a wrapper function efi_map_region_fixed [02/09]
check return value of krealloc
sysfs dir name s/efi-runtime-map/runtime-map [06/09]
use desc_size in efi_runtime_map
for the xloadflags defination: +&& defined(CONFIG_KEXEC)
Greg: sysfs : one file one value for fw_vendor, runtime, tables. [05/09]
Document them in ABI testing
HPA: Document the new xloadflag
Also there's other function cleanup and improvement for error handling.
Changes from v3:
Greg: sysfs code move to use __ATTR_RO and attr_group
Boris: comments and code alignment
Added 3 new patches below
10-print-efi-runtime-memmap.patch
- 10/12: print only runtime ranges in case EFI_DEBUG printing
11-reserve-setup-data-late.patch
- fix a bug of kdump kernel, move function for reserving setup data
ranges late after parsing memmap= cmdline params because kdump kernel
will pass exact memmap late.
12-x86-kdebugfs-use-ioremap.patch
- fix a bug of x86/kernel/kdebugfs.c, use ioremap instead of __va for
low mem because __va does not work for exact memmap=
Changes from V4:
- variable efi_setup in 09/14 is changed to the physical address instead of the virtual address
because it will be not iounmapped until entering virtual mode, it's too long and could cause
leak.
- sparse warnings fixes (Matt):
Added 2 new patches to addressing sparse warnings:
01/14: x86-mm-sparse-warning-fix-for-early_memremap.patch
02/14: efi-use-early_memremap-and-early_memunmap.patch
- krealloc fixes (Boris)
- rebase on top of Linus tree + Matt's efi master tree (Boris)
- a lot of documention/spelling fixes (Boris)
- share function save_runtime_map in 1st/2nd kernel code (Matt)
- style and other fixes detail see the patch changelog themselves.
Boris: I still use the function name efi_reuse_config because it could be not only a problem for
HP workstation, also because we will later split them to another file so efi_ is acceptable for me.
The patches stay in kexec-efi-testing branch of below repo for testing:
https://github.com/daveyoung/linux.git
Dave Young (14):
x86/mm: sparse warning fix for early_memremap
efi: use early_memremap and early_memunmap
efi: remove unused variables in __map_region
efi: add a wrapper function efi_map_region_fixed
efi: reserve boot service fix
efi: cleanup efi_enter_virtual_mode function
efi: export more efi table variable to sysfs
efi: export efi runtime memory mapping to sysfs
efi: passing kexec necessary efi data via setup_data
efi: only print saved efi runtime maps instead of all memmap ranges
for kexec
x86: add xloadflags bit for efi runtime support on kexec
x86: export x86 boot_params to sysfs
x86: reserve setup_data ranges late after parsing memmap cmdline
x86: kdebugfs do not use __va for getting setup_data virt addr
Documentation/ABI/testing/sysfs-firmware-efi | 24 ++
.../ABI/testing/sysfs-firmware-efi-runtime-map | 36 ++
Documentation/ABI/testing/sysfs-kernel-boot_params | 39 +++
Documentation/x86/boot.txt | 3 +
arch/x86/boot/header.S | 9 +-
arch/x86/include/asm/efi.h | 12 +
arch/x86/include/asm/io.h | 3 +-
arch/x86/include/uapi/asm/bootparam.h | 2 +
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/kdebugfs.c | 35 +-
arch/x86/kernel/ksysfs.c | 339 ++++++++++++++++++
arch/x86/kernel/setup.c | 7 +-
arch/x86/mm/ioremap.c | 10 +-
arch/x86/platform/efi/efi.c | 378 ++++++++++++++++-----
arch/x86/platform/efi/efi_32.c | 2 +
arch/x86/platform/efi/efi_64.c | 16 +-
drivers/firmware/efi/Kconfig | 11 +
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/efi.c | 47 ++-
drivers/firmware/efi/runtime-map.c | 176 ++++++++++
include/linux/efi.h | 9 +
21 files changed, 1038 insertions(+), 122 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi
create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
create mode 100644 Documentation/ABI/testing/sysfs-kernel-boot_params
create mode 100644 arch/x86/kernel/ksysfs.c
create mode 100644 drivers/firmware/efi/runtime-map.c
--
1.8.3.1
^ permalink raw reply [flat|nested] 183+ messages in thread* [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
There's a lot of sparse warnings for code like below:
void *a = early_memremap(phys_addr, size);
early_memremap intend to map kernel memory with ioremap facility, the return
pointer should be a kernel ram pointer instead of iomem one.
For making the function clearer and supressing sparse warnings this patch
do below two things:
1. cast to (__force void *) for the return value of early_memremap
2. add early_memunmap function and pass (__force void __iomem *) to iounmap
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/include/asm/io.h | 3 ++-
arch/x86/mm/ioremap.c | 10 +++++++---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 34f69cb..1db414f 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -325,9 +325,10 @@ extern void early_ioremap_init(void);
extern void early_ioremap_reset(void);
extern void __iomem *early_ioremap(resource_size_t phys_addr,
unsigned long size);
-extern void __iomem *early_memremap(resource_size_t phys_addr,
+extern void *early_memremap(resource_size_t phys_addr,
unsigned long size);
extern void early_iounmap(void __iomem *addr, unsigned long size);
+extern void early_memunmap(void *addr, unsigned long size);
extern void fixup_early_ioremap(void);
extern bool is_early_ioremap_ptep(pte_t *ptep);
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 799580c..bbb4504 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -562,10 +562,9 @@ early_ioremap(resource_size_t phys_addr, unsigned long size)
}
/* Remap memory */
-void __init __iomem *
-early_memremap(resource_size_t phys_addr, unsigned long size)
+void __init *early_memremap(resource_size_t phys_addr, unsigned long size)
{
- return __early_ioremap(phys_addr, size, PAGE_KERNEL);
+ return (__force void *)__early_ioremap(phys_addr, size, PAGE_KERNEL);
}
void __init early_iounmap(void __iomem *addr, unsigned long size)
@@ -620,3 +619,8 @@ void __init early_iounmap(void __iomem *addr, unsigned long size)
}
prev_map[slot] = NULL;
}
+
+void __init early_memunmap(void *addr, unsigned long size)
+{
+ early_iounmap((__force void __iomem *)addr, size);
+}
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
There's a lot of sparse warnings for code like below:
void *a = early_memremap(phys_addr, size);
early_memremap intend to map kernel memory with ioremap facility, the return
pointer should be a kernel ram pointer instead of iomem one.
For making the function clearer and supressing sparse warnings this patch
do below two things:
1. cast to (__force void *) for the return value of early_memremap
2. add early_memunmap function and pass (__force void __iomem *) to iounmap
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/include/asm/io.h | 3 ++-
arch/x86/mm/ioremap.c | 10 +++++++---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 34f69cb..1db414f 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -325,9 +325,10 @@ extern void early_ioremap_init(void);
extern void early_ioremap_reset(void);
extern void __iomem *early_ioremap(resource_size_t phys_addr,
unsigned long size);
-extern void __iomem *early_memremap(resource_size_t phys_addr,
+extern void *early_memremap(resource_size_t phys_addr,
unsigned long size);
extern void early_iounmap(void __iomem *addr, unsigned long size);
+extern void early_memunmap(void *addr, unsigned long size);
extern void fixup_early_ioremap(void);
extern bool is_early_ioremap_ptep(pte_t *ptep);
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 799580c..bbb4504 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -562,10 +562,9 @@ early_ioremap(resource_size_t phys_addr, unsigned long size)
}
/* Remap memory */
-void __init __iomem *
-early_memremap(resource_size_t phys_addr, unsigned long size)
+void __init *early_memremap(resource_size_t phys_addr, unsigned long size)
{
- return __early_ioremap(phys_addr, size, PAGE_KERNEL);
+ return (__force void *)__early_ioremap(phys_addr, size, PAGE_KERNEL);
}
void __init early_iounmap(void __iomem *addr, unsigned long size)
@@ -620,3 +619,8 @@ void __init early_iounmap(void __iomem *addr, unsigned long size)
}
prev_map[slot] = NULL;
}
+
+void __init early_memunmap(void *addr, unsigned long size)
+{
+ early_iounmap((__force void __iomem *)addr, size);
+}
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bp-Gina5bIWoIWzQB+pC5nmwQ, greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
There's a lot of sparse warnings for code like below:
void *a = early_memremap(phys_addr, size);
early_memremap intend to map kernel memory with ioremap facility, the return
pointer should be a kernel ram pointer instead of iomem one.
For making the function clearer and supressing sparse warnings this patch
do below two things:
1. cast to (__force void *) for the return value of early_memremap
2. add early_memunmap function and pass (__force void __iomem *) to iounmap
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
arch/x86/include/asm/io.h | 3 ++-
arch/x86/mm/ioremap.c | 10 +++++++---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 34f69cb..1db414f 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -325,9 +325,10 @@ extern void early_ioremap_init(void);
extern void early_ioremap_reset(void);
extern void __iomem *early_ioremap(resource_size_t phys_addr,
unsigned long size);
-extern void __iomem *early_memremap(resource_size_t phys_addr,
+extern void *early_memremap(resource_size_t phys_addr,
unsigned long size);
extern void early_iounmap(void __iomem *addr, unsigned long size);
+extern void early_memunmap(void *addr, unsigned long size);
extern void fixup_early_ioremap(void);
extern bool is_early_ioremap_ptep(pte_t *ptep);
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 799580c..bbb4504 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -562,10 +562,9 @@ early_ioremap(resource_size_t phys_addr, unsigned long size)
}
/* Remap memory */
-void __init __iomem *
-early_memremap(resource_size_t phys_addr, unsigned long size)
+void __init *early_memremap(resource_size_t phys_addr, unsigned long size)
{
- return __early_ioremap(phys_addr, size, PAGE_KERNEL);
+ return (__force void *)__early_ioremap(phys_addr, size, PAGE_KERNEL);
}
void __init early_iounmap(void __iomem *addr, unsigned long size)
@@ -620,3 +619,8 @@ void __init early_iounmap(void __iomem *addr, unsigned long size)
}
prev_map[slot] = NULL;
}
+
+void __init early_memunmap(void *addr, unsigned long size)
+{
+ early_iounmap((__force void __iomem *)addr, size);
+}
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-09 15:05 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-09 15:05 UTC (permalink / raw)
To: Dave Young, H. Peter Anvin, Ingo Molnar
Cc: linux-kernel, linux-efi, x86, mjg59, James.Bottomley, vgoyal,
ebiederm, horms, kexec, greg, matt, toshi.kani
On Mon, Dec 09, 2013 at 05:42:14PM +0800, Dave Young wrote:
> There's a lot of sparse warnings for code like below:
> void *a = early_memremap(phys_addr, size);
>
> early_memremap intend to map kernel memory with ioremap facility, the return
> pointer should be a kernel ram pointer instead of iomem one.
>
> For making the function clearer and supressing sparse warnings this patch
> do below two things:
> 1. cast to (__force void *) for the return value of early_memremap
I'd guess this is to shut up the __iomem thing? And we're getting that
because we're using ioremap, ... hohum...
> 2. add early_memunmap function and pass (__force void __iomem *) to iounmap
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/include/asm/io.h | 3 ++-
> arch/x86/mm/ioremap.c | 10 +++++++---
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 34f69cb..1db414f 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -325,9 +325,10 @@ extern void early_ioremap_init(void);
> extern void early_ioremap_reset(void);
> extern void __iomem *early_ioremap(resource_size_t phys_addr,
> unsigned long size);
> -extern void __iomem *early_memremap(resource_size_t phys_addr,
> +extern void *early_memremap(resource_size_t phys_addr,
> unsigned long size);
> extern void early_iounmap(void __iomem *addr, unsigned long size);
> +extern void early_memunmap(void *addr, unsigned long size);
> extern void fixup_early_ioremap(void);
> extern bool is_early_ioremap_ptep(pte_t *ptep);
>
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 799580c..bbb4504 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -562,10 +562,9 @@ early_ioremap(resource_size_t phys_addr, unsigned long size)
> }
>
> /* Remap memory */
> -void __init __iomem *
> -early_memremap(resource_size_t phys_addr, unsigned long size)
> +void __init *early_memremap(resource_size_t phys_addr, unsigned long size)
Btw, the patch that added memremap was
commit 1494177942b23b7094ca291d37e6f6263fa60fdd
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date: Sun Sep 7 15:21:15 2008 -0700
x86: add early_memremap()
and AFAICR, the intention really was to do normal memory mapping through
ioremap.
Then
commit 1d6cf1feb854c53c6d59e0d879603692b379e208
Author: Harvey Harrison <harvey.harrison@gmail.com>
Date: Tue Oct 28 22:46:04 2008 -0700
x86: start annotating early ioremap pointers with __iomem
Impact: some new sparse warnings in e820.c etc, but no functional change.
As with regular ioremap, iounmap etc, annotate with __iomem.
went and added the __iomem sparse attributes annotation which doesn't
make any sense to me since the original intention of memremap was to
give *normal* memory and not io memory. IOW, memory we can *certainly*
*deref* and which is in the same address space so __iomem is completely
wrong and ass backwards to put there.
But I'm not all that sure.
hpa, Ingo, what do you guys think?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-09 15:05 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-09 15:05 UTC (permalink / raw)
To: Dave Young, H. Peter Anvin, Ingo Molnar
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, vgoyal
On Mon, Dec 09, 2013 at 05:42:14PM +0800, Dave Young wrote:
> There's a lot of sparse warnings for code like below:
> void *a = early_memremap(phys_addr, size);
>
> early_memremap intend to map kernel memory with ioremap facility, the return
> pointer should be a kernel ram pointer instead of iomem one.
>
> For making the function clearer and supressing sparse warnings this patch
> do below two things:
> 1. cast to (__force void *) for the return value of early_memremap
I'd guess this is to shut up the __iomem thing? And we're getting that
because we're using ioremap, ... hohum...
> 2. add early_memunmap function and pass (__force void __iomem *) to iounmap
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/include/asm/io.h | 3 ++-
> arch/x86/mm/ioremap.c | 10 +++++++---
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 34f69cb..1db414f 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -325,9 +325,10 @@ extern void early_ioremap_init(void);
> extern void early_ioremap_reset(void);
> extern void __iomem *early_ioremap(resource_size_t phys_addr,
> unsigned long size);
> -extern void __iomem *early_memremap(resource_size_t phys_addr,
> +extern void *early_memremap(resource_size_t phys_addr,
> unsigned long size);
> extern void early_iounmap(void __iomem *addr, unsigned long size);
> +extern void early_memunmap(void *addr, unsigned long size);
> extern void fixup_early_ioremap(void);
> extern bool is_early_ioremap_ptep(pte_t *ptep);
>
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 799580c..bbb4504 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -562,10 +562,9 @@ early_ioremap(resource_size_t phys_addr, unsigned long size)
> }
>
> /* Remap memory */
> -void __init __iomem *
> -early_memremap(resource_size_t phys_addr, unsigned long size)
> +void __init *early_memremap(resource_size_t phys_addr, unsigned long size)
Btw, the patch that added memremap was
commit 1494177942b23b7094ca291d37e6f6263fa60fdd
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date: Sun Sep 7 15:21:15 2008 -0700
x86: add early_memremap()
and AFAICR, the intention really was to do normal memory mapping through
ioremap.
Then
commit 1d6cf1feb854c53c6d59e0d879603692b379e208
Author: Harvey Harrison <harvey.harrison@gmail.com>
Date: Tue Oct 28 22:46:04 2008 -0700
x86: start annotating early ioremap pointers with __iomem
Impact: some new sparse warnings in e820.c etc, but no functional change.
As with regular ioremap, iounmap etc, annotate with __iomem.
went and added the __iomem sparse attributes annotation which doesn't
make any sense to me since the original intention of memremap was to
give *normal* memory and not io memory. IOW, memory we can *certainly*
*deref* and which is in the same address space so __iomem is completely
wrong and ass backwards to put there.
But I'm not all that sure.
hpa, Ingo, what do you guys think?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-09 15:05 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-09 15:05 UTC (permalink / raw)
To: Dave Young, H. Peter Anvin, Ingo Molnar
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On Mon, Dec 09, 2013 at 05:42:14PM +0800, Dave Young wrote:
> There's a lot of sparse warnings for code like below:
> void *a = early_memremap(phys_addr, size);
>
> early_memremap intend to map kernel memory with ioremap facility, the return
> pointer should be a kernel ram pointer instead of iomem one.
>
> For making the function clearer and supressing sparse warnings this patch
> do below two things:
> 1. cast to (__force void *) for the return value of early_memremap
I'd guess this is to shut up the __iomem thing? And we're getting that
because we're using ioremap, ... hohum...
> 2. add early_memunmap function and pass (__force void __iomem *) to iounmap
>
> Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> arch/x86/include/asm/io.h | 3 ++-
> arch/x86/mm/ioremap.c | 10 +++++++---
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 34f69cb..1db414f 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -325,9 +325,10 @@ extern void early_ioremap_init(void);
> extern void early_ioremap_reset(void);
> extern void __iomem *early_ioremap(resource_size_t phys_addr,
> unsigned long size);
> -extern void __iomem *early_memremap(resource_size_t phys_addr,
> +extern void *early_memremap(resource_size_t phys_addr,
> unsigned long size);
> extern void early_iounmap(void __iomem *addr, unsigned long size);
> +extern void early_memunmap(void *addr, unsigned long size);
> extern void fixup_early_ioremap(void);
> extern bool is_early_ioremap_ptep(pte_t *ptep);
>
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 799580c..bbb4504 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -562,10 +562,9 @@ early_ioremap(resource_size_t phys_addr, unsigned long size)
> }
>
> /* Remap memory */
> -void __init __iomem *
> -early_memremap(resource_size_t phys_addr, unsigned long size)
> +void __init *early_memremap(resource_size_t phys_addr, unsigned long size)
Btw, the patch that added memremap was
commit 1494177942b23b7094ca291d37e6f6263fa60fdd
Author: Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>
Date: Sun Sep 7 15:21:15 2008 -0700
x86: add early_memremap()
and AFAICR, the intention really was to do normal memory mapping through
ioremap.
Then
commit 1d6cf1feb854c53c6d59e0d879603692b379e208
Author: Harvey Harrison <harvey.harrison-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue Oct 28 22:46:04 2008 -0700
x86: start annotating early ioremap pointers with __iomem
Impact: some new sparse warnings in e820.c etc, but no functional change.
As with regular ioremap, iounmap etc, annotate with __iomem.
went and added the __iomem sparse attributes annotation which doesn't
make any sense to me since the original intention of memremap was to
give *normal* memory and not io memory. IOW, memory we can *certainly*
*deref* and which is in the same address space so __iomem is completely
wrong and ass backwards to put there.
But I'm not all that sure.
hpa, Ingo, what do you guys think?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-10 2:12 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-10 2:12 UTC (permalink / raw)
To: Borislav Petkov
Cc: H. Peter Anvin, Ingo Molnar, linux-kernel, linux-efi, x86, mjg59,
James.Bottomley, vgoyal, ebiederm, horms, kexec, greg, matt,
toshi.kani
On 12/09/13 at 04:05pm, Borislav Petkov wrote:
> On Mon, Dec 09, 2013 at 05:42:14PM +0800, Dave Young wrote:
> > There's a lot of sparse warnings for code like below:
> > void *a = early_memremap(phys_addr, size);
> >
> > early_memremap intend to map kernel memory with ioremap facility, the return
> > pointer should be a kernel ram pointer instead of iomem one.
> >
> > For making the function clearer and supressing sparse warnings this patch
> > do below two things:
> > 1. cast to (__force void *) for the return value of early_memremap
>
> I'd guess this is to shut up the __iomem thing? And we're getting that
> because we're using ioremap, ... hohum...
Yes, IMHO early_memremap really should not return __iomem pointer since it's
*memremap*...
Thanks
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-10 2:12 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-10 2:12 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, H. Peter Anvin,
Ingo Molnar, vgoyal
On 12/09/13 at 04:05pm, Borislav Petkov wrote:
> On Mon, Dec 09, 2013 at 05:42:14PM +0800, Dave Young wrote:
> > There's a lot of sparse warnings for code like below:
> > void *a = early_memremap(phys_addr, size);
> >
> > early_memremap intend to map kernel memory with ioremap facility, the return
> > pointer should be a kernel ram pointer instead of iomem one.
> >
> > For making the function clearer and supressing sparse warnings this patch
> > do below two things:
> > 1. cast to (__force void *) for the return value of early_memremap
>
> I'd guess this is to shut up the __iomem thing? And we're getting that
> because we're using ioremap, ... hohum...
Yes, IMHO early_memremap really should not return __iomem pointer since it's
*memremap*...
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-10 2:12 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-10 2:12 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
H. Peter Anvin, Ingo Molnar, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On 12/09/13 at 04:05pm, Borislav Petkov wrote:
> On Mon, Dec 09, 2013 at 05:42:14PM +0800, Dave Young wrote:
> > There's a lot of sparse warnings for code like below:
> > void *a = early_memremap(phys_addr, size);
> >
> > early_memremap intend to map kernel memory with ioremap facility, the return
> > pointer should be a kernel ram pointer instead of iomem one.
> >
> > For making the function clearer and supressing sparse warnings this patch
> > do below two things:
> > 1. cast to (__force void *) for the return value of early_memremap
>
> I'd guess this is to shut up the __iomem thing? And we're getting that
> because we're using ioremap, ... hohum...
Yes, IMHO early_memremap really should not return __iomem pointer since it's
*memremap*...
Thanks
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-11 10:20 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 10:20 UTC (permalink / raw)
To: Dave Young
Cc: Borislav Petkov, H. Peter Anvin, Ingo Molnar, linux-kernel,
linux-efi, x86, mjg59, James.Bottomley, vgoyal, ebiederm, horms,
kexec, greg, toshi.kani
On Tue, 10 Dec, at 10:12:21AM, Dave Young wrote:
> On 12/09/13 at 04:05pm, Borislav Petkov wrote:
> > On Mon, Dec 09, 2013 at 05:42:14PM +0800, Dave Young wrote:
> > > There's a lot of sparse warnings for code like below:
> > > void *a = early_memremap(phys_addr, size);
> > >
> > > early_memremap intend to map kernel memory with ioremap facility, the return
> > > pointer should be a kernel ram pointer instead of iomem one.
> > >
> > > For making the function clearer and supressing sparse warnings this patch
> > > do below two things:
> > > 1. cast to (__force void *) for the return value of early_memremap
> >
> > I'd guess this is to shut up the __iomem thing? And we're getting that
> > because we're using ioremap, ... hohum...
>
> Yes, IMHO early_memremap really should not return __iomem pointer since it's
> *memremap*...
This needs reviewing by at least one of the x86 folks, but it certainly
makes sense to me.
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-11 10:20 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 10:20 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, greg, x86, kexec, linux-kernel,
James.Bottomley, horms, Borislav Petkov, ebiederm,
H. Peter Anvin, Ingo Molnar, vgoyal
On Tue, 10 Dec, at 10:12:21AM, Dave Young wrote:
> On 12/09/13 at 04:05pm, Borislav Petkov wrote:
> > On Mon, Dec 09, 2013 at 05:42:14PM +0800, Dave Young wrote:
> > > There's a lot of sparse warnings for code like below:
> > > void *a = early_memremap(phys_addr, size);
> > >
> > > early_memremap intend to map kernel memory with ioremap facility, the return
> > > pointer should be a kernel ram pointer instead of iomem one.
> > >
> > > For making the function clearer and supressing sparse warnings this patch
> > > do below two things:
> > > 1. cast to (__force void *) for the return value of early_memremap
> >
> > I'd guess this is to shut up the __iomem thing? And we're getting that
> > because we're using ioremap, ... hohum...
>
> Yes, IMHO early_memremap really should not return __iomem pointer since it's
> *memremap*...
This needs reviewing by at least one of the x86 folks, but it certainly
makes sense to me.
--
Matt Fleming, Intel Open Source Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-11 10:20 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 10:20 UTC (permalink / raw)
To: Dave Young
Cc: Borislav Petkov, H. Peter Anvin, Ingo Molnar,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w, toshi.kani-VXdhtT5mjnY
On Tue, 10 Dec, at 10:12:21AM, Dave Young wrote:
> On 12/09/13 at 04:05pm, Borislav Petkov wrote:
> > On Mon, Dec 09, 2013 at 05:42:14PM +0800, Dave Young wrote:
> > > There's a lot of sparse warnings for code like below:
> > > void *a = early_memremap(phys_addr, size);
> > >
> > > early_memremap intend to map kernel memory with ioremap facility, the return
> > > pointer should be a kernel ram pointer instead of iomem one.
> > >
> > > For making the function clearer and supressing sparse warnings this patch
> > > do below two things:
> > > 1. cast to (__force void *) for the return value of early_memremap
> >
> > I'd guess this is to shut up the __iomem thing? And we're getting that
> > because we're using ioremap, ... hohum...
>
> Yes, IMHO early_memremap really should not return __iomem pointer since it's
> *memremap*...
This needs reviewing by at least one of the x86 folks, but it certainly
makes sense to me.
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
2013-12-11 10:20 ` Matt Fleming
@ 2013-12-11 11:12 ` Borislav Petkov
-1 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 11:12 UTC (permalink / raw)
To: Matt Fleming
Cc: Dave Young, H. Peter Anvin, Ingo Molnar, linux-kernel, linux-efi,
x86, mjg59, James.Bottomley, vgoyal, ebiederm, horms, kexec,
greg, toshi.kani
On Wed, Dec 11, 2013 at 10:20:25AM +0000, Matt Fleming wrote:
> This needs reviewing by at least one of the x86 folks, but it
> certainly makes sense to me.
Ingo told me yesterday, it makes sense too. I'd guess we can try it.
FWIW, all callers of early_memremap use the memory they get remapped as
normal memory so we should be safe.
Maybe this whole discussion should be noted down in the commit message
so that people know.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-11 11:12 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 11:12 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59, linux-efi, toshi.kani, greg, x86, kexec, linux-kernel,
James.Bottomley, horms, ebiederm, H. Peter Anvin, Dave Young,
Ingo Molnar, vgoyal
On Wed, Dec 11, 2013 at 10:20:25AM +0000, Matt Fleming wrote:
> This needs reviewing by at least one of the x86 folks, but it
> certainly makes sense to me.
Ingo told me yesterday, it makes sense too. I'd guess we can try it.
FWIW, all callers of early_memremap use the memory they get remapped as
normal memory so we should be safe.
Maybe this whole discussion should be noted down in the commit message
so that people know.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-12 2:06 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: Matt Fleming, H. Peter Anvin, Ingo Molnar, linux-kernel,
linux-efi, x86, mjg59, James.Bottomley, vgoyal, ebiederm, horms,
kexec, greg, toshi.kani
On 12/11/13 at 12:12pm, Borislav Petkov wrote:
> On Wed, Dec 11, 2013 at 10:20:25AM +0000, Matt Fleming wrote:
> > This needs reviewing by at least one of the x86 folks, but it
> > certainly makes sense to me.
>
> Ingo told me yesterday, it makes sense too. I'd guess we can try it.
> FWIW, all callers of early_memremap use the memory they get remapped as
> normal memory so we should be safe.
>
> Maybe this whole discussion should be noted down in the commit message
> so that people know.
Thanks for the info. will add.
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-12 2:06 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: Matt Fleming, linux-efi, toshi.kani, mjg59, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, H. Peter Anvin,
Ingo Molnar, vgoyal
On 12/11/13 at 12:12pm, Borislav Petkov wrote:
> On Wed, Dec 11, 2013 at 10:20:25AM +0000, Matt Fleming wrote:
> > This needs reviewing by at least one of the x86 folks, but it
> > certainly makes sense to me.
>
> Ingo told me yesterday, it makes sense too. I'd guess we can try it.
> FWIW, all callers of early_memremap use the memory they get remapped as
> normal memory so we should be safe.
>
> Maybe this whole discussion should be noted down in the commit message
> so that people know.
Thanks for the info. will add.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 01/14] x86/mm: sparse warning fix for early_memremap
@ 2013-12-12 2:06 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: Matt Fleming, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, mjg59-1xO5oi07KQx4cg9Nei1l7Q,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
H. Peter Anvin, Ingo Molnar, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On 12/11/13 at 12:12pm, Borislav Petkov wrote:
> On Wed, Dec 11, 2013 at 10:20:25AM +0000, Matt Fleming wrote:
> > This needs reviewing by at least one of the x86 folks, but it
> > certainly makes sense to me.
>
> Ingo told me yesterday, it makes sense too. I'd guess we can try it.
> FWIW, all callers of early_memremap use the memory they get remapped as
> normal memory so we should be safe.
>
> Maybe this whole discussion should be noted down in the commit message
> so that people know.
Thanks for the info. will add.
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
In arch/x86/platform/efi/efi.c and drivers/firmware/efi/efi.c turn to use
early_memremap/early_memunmap instead of early_ioremap/early_iounmap so sparse
will be happy.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/platform/efi/efi.c | 20 ++++++++++----------
drivers/firmware/efi/efi.c | 4 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index f8ec4da..ef471d5 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -456,7 +456,7 @@ void __init efi_unmap_memmap(void)
{
clear_bit(EFI_MEMMAP, &x86_efi_facility);
if (memmap.map) {
- early_iounmap(memmap.map, memmap.nr_map * memmap.desc_size);
+ early_memunmap(memmap.map, memmap.nr_map * memmap.desc_size);
memmap.map = NULL;
}
}
@@ -493,7 +493,7 @@ static int __init efi_systab_init(void *phys)
efi_system_table_64_t *systab64;
u64 tmp = 0;
- systab64 = early_ioremap((unsigned long)phys,
+ systab64 = early_memremap((unsigned long)phys,
sizeof(*systab64));
if (systab64 == NULL) {
pr_err("Couldn't map the system table!\n");
@@ -524,7 +524,7 @@ static int __init efi_systab_init(void *phys)
efi_systab.tables = systab64->tables;
tmp |= systab64->tables;
- early_iounmap(systab64, sizeof(*systab64));
+ early_memunmap(systab64, sizeof(*systab64));
#ifdef CONFIG_X86_32
if (tmp >> 32) {
pr_err("EFI data located above 4GB, disabling EFI.\n");
@@ -534,7 +534,7 @@ static int __init efi_systab_init(void *phys)
} else {
efi_system_table_32_t *systab32;
- systab32 = early_ioremap((unsigned long)phys,
+ systab32 = early_memremap((unsigned long)phys,
sizeof(*systab32));
if (systab32 == NULL) {
pr_err("Couldn't map the system table!\n");
@@ -555,7 +555,7 @@ static int __init efi_systab_init(void *phys)
efi_systab.nr_tables = systab32->nr_tables;
efi_systab.tables = systab32->tables;
- early_iounmap(systab32, sizeof(*systab32));
+ early_memunmap(systab32, sizeof(*systab32));
}
efi.systab = &efi_systab;
@@ -586,7 +586,7 @@ static int __init efi_runtime_init(void)
* address of several of the EFI runtime functions, needed to
* set the firmware into virtual mode.
*/
- runtime = early_ioremap((unsigned long)efi.systab->runtime,
+ runtime = early_memremap((unsigned long)efi.systab->runtime,
sizeof(efi_runtime_services_t));
if (!runtime) {
pr_err("Could not map the runtime service table!\n");
@@ -606,7 +606,7 @@ static int __init efi_runtime_init(void)
* virtual mode.
*/
efi.get_time = phys_efi_get_time;
- early_iounmap(runtime, sizeof(efi_runtime_services_t));
+ early_memunmap(runtime, sizeof(efi_runtime_services_t));
return 0;
}
@@ -614,7 +614,7 @@ static int __init efi_runtime_init(void)
static int __init efi_memmap_init(void)
{
/* Map the EFI memory map */
- memmap.map = early_ioremap((unsigned long)memmap.phys_map,
+ memmap.map = early_memremap((unsigned long)memmap.phys_map,
memmap.nr_map * memmap.desc_size);
if (memmap.map == NULL) {
pr_err("Could not map the memory map!\n");
@@ -656,14 +656,14 @@ void __init efi_init(void)
/*
* Show what we know for posterity
*/
- c16 = tmp = early_ioremap(efi.systab->fw_vendor, 2);
+ c16 = tmp = early_memremap(efi.systab->fw_vendor, 2);
if (c16) {
for (i = 0; i < sizeof(vendor) - 1 && *c16; ++i)
vendor[i] = *c16++;
vendor[i] = '\0';
} else
pr_err("Could not map the firmware vendor!\n");
- early_iounmap(tmp, 2);
+ early_memunmap(tmp, 2);
pr_info("EFI v%u.%.02u by %s\n",
efi.systab->hdr.revision >> 16,
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2e2fbde..b716a66 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -253,7 +253,7 @@ int __init efi_config_init(efi_config_table_type_t *arch_tables)
if (table64 >> 32) {
pr_cont("\n");
pr_err("Table located above 4GB, disabling EFI.\n");
- early_iounmap(config_tables,
+ early_memunmap(config_tables,
efi.systab->nr_tables * sz);
return -EINVAL;
}
@@ -269,6 +269,6 @@ int __init efi_config_init(efi_config_table_type_t *arch_tables)
tablep += sz;
}
pr_cont("\n");
- early_iounmap(config_tables, efi.systab->nr_tables * sz);
+ early_memunmap(config_tables, efi.systab->nr_tables * sz);
return 0;
}
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
In arch/x86/platform/efi/efi.c and drivers/firmware/efi/efi.c turn to use
early_memremap/early_memunmap instead of early_ioremap/early_iounmap so sparse
will be happy.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/platform/efi/efi.c | 20 ++++++++++----------
drivers/firmware/efi/efi.c | 4 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index f8ec4da..ef471d5 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -456,7 +456,7 @@ void __init efi_unmap_memmap(void)
{
clear_bit(EFI_MEMMAP, &x86_efi_facility);
if (memmap.map) {
- early_iounmap(memmap.map, memmap.nr_map * memmap.desc_size);
+ early_memunmap(memmap.map, memmap.nr_map * memmap.desc_size);
memmap.map = NULL;
}
}
@@ -493,7 +493,7 @@ static int __init efi_systab_init(void *phys)
efi_system_table_64_t *systab64;
u64 tmp = 0;
- systab64 = early_ioremap((unsigned long)phys,
+ systab64 = early_memremap((unsigned long)phys,
sizeof(*systab64));
if (systab64 == NULL) {
pr_err("Couldn't map the system table!\n");
@@ -524,7 +524,7 @@ static int __init efi_systab_init(void *phys)
efi_systab.tables = systab64->tables;
tmp |= systab64->tables;
- early_iounmap(systab64, sizeof(*systab64));
+ early_memunmap(systab64, sizeof(*systab64));
#ifdef CONFIG_X86_32
if (tmp >> 32) {
pr_err("EFI data located above 4GB, disabling EFI.\n");
@@ -534,7 +534,7 @@ static int __init efi_systab_init(void *phys)
} else {
efi_system_table_32_t *systab32;
- systab32 = early_ioremap((unsigned long)phys,
+ systab32 = early_memremap((unsigned long)phys,
sizeof(*systab32));
if (systab32 == NULL) {
pr_err("Couldn't map the system table!\n");
@@ -555,7 +555,7 @@ static int __init efi_systab_init(void *phys)
efi_systab.nr_tables = systab32->nr_tables;
efi_systab.tables = systab32->tables;
- early_iounmap(systab32, sizeof(*systab32));
+ early_memunmap(systab32, sizeof(*systab32));
}
efi.systab = &efi_systab;
@@ -586,7 +586,7 @@ static int __init efi_runtime_init(void)
* address of several of the EFI runtime functions, needed to
* set the firmware into virtual mode.
*/
- runtime = early_ioremap((unsigned long)efi.systab->runtime,
+ runtime = early_memremap((unsigned long)efi.systab->runtime,
sizeof(efi_runtime_services_t));
if (!runtime) {
pr_err("Could not map the runtime service table!\n");
@@ -606,7 +606,7 @@ static int __init efi_runtime_init(void)
* virtual mode.
*/
efi.get_time = phys_efi_get_time;
- early_iounmap(runtime, sizeof(efi_runtime_services_t));
+ early_memunmap(runtime, sizeof(efi_runtime_services_t));
return 0;
}
@@ -614,7 +614,7 @@ static int __init efi_runtime_init(void)
static int __init efi_memmap_init(void)
{
/* Map the EFI memory map */
- memmap.map = early_ioremap((unsigned long)memmap.phys_map,
+ memmap.map = early_memremap((unsigned long)memmap.phys_map,
memmap.nr_map * memmap.desc_size);
if (memmap.map == NULL) {
pr_err("Could not map the memory map!\n");
@@ -656,14 +656,14 @@ void __init efi_init(void)
/*
* Show what we know for posterity
*/
- c16 = tmp = early_ioremap(efi.systab->fw_vendor, 2);
+ c16 = tmp = early_memremap(efi.systab->fw_vendor, 2);
if (c16) {
for (i = 0; i < sizeof(vendor) - 1 && *c16; ++i)
vendor[i] = *c16++;
vendor[i] = '\0';
} else
pr_err("Could not map the firmware vendor!\n");
- early_iounmap(tmp, 2);
+ early_memunmap(tmp, 2);
pr_info("EFI v%u.%.02u by %s\n",
efi.systab->hdr.revision >> 16,
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2e2fbde..b716a66 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -253,7 +253,7 @@ int __init efi_config_init(efi_config_table_type_t *arch_tables)
if (table64 >> 32) {
pr_cont("\n");
pr_err("Table located above 4GB, disabling EFI.\n");
- early_iounmap(config_tables,
+ early_memunmap(config_tables,
efi.systab->nr_tables * sz);
return -EINVAL;
}
@@ -269,6 +269,6 @@ int __init efi_config_init(efi_config_table_type_t *arch_tables)
tablep += sz;
}
pr_cont("\n");
- early_iounmap(config_tables, efi.systab->nr_tables * sz);
+ early_memunmap(config_tables, efi.systab->nr_tables * sz);
return 0;
}
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
In arch/x86/platform/efi/efi.c and drivers/firmware/efi/efi.c turn to use
early_memremap/early_memunmap instead of early_ioremap/early_iounmap so sparse
will be happy.
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
arch/x86/platform/efi/efi.c | 20 ++++++++++----------
drivers/firmware/efi/efi.c | 4 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index f8ec4da..ef471d5 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -456,7 +456,7 @@ void __init efi_unmap_memmap(void)
{
clear_bit(EFI_MEMMAP, &x86_efi_facility);
if (memmap.map) {
- early_iounmap(memmap.map, memmap.nr_map * memmap.desc_size);
+ early_memunmap(memmap.map, memmap.nr_map * memmap.desc_size);
memmap.map = NULL;
}
}
@@ -493,7 +493,7 @@ static int __init efi_systab_init(void *phys)
efi_system_table_64_t *systab64;
u64 tmp = 0;
- systab64 = early_ioremap((unsigned long)phys,
+ systab64 = early_memremap((unsigned long)phys,
sizeof(*systab64));
if (systab64 == NULL) {
pr_err("Couldn't map the system table!\n");
@@ -524,7 +524,7 @@ static int __init efi_systab_init(void *phys)
efi_systab.tables = systab64->tables;
tmp |= systab64->tables;
- early_iounmap(systab64, sizeof(*systab64));
+ early_memunmap(systab64, sizeof(*systab64));
#ifdef CONFIG_X86_32
if (tmp >> 32) {
pr_err("EFI data located above 4GB, disabling EFI.\n");
@@ -534,7 +534,7 @@ static int __init efi_systab_init(void *phys)
} else {
efi_system_table_32_t *systab32;
- systab32 = early_ioremap((unsigned long)phys,
+ systab32 = early_memremap((unsigned long)phys,
sizeof(*systab32));
if (systab32 == NULL) {
pr_err("Couldn't map the system table!\n");
@@ -555,7 +555,7 @@ static int __init efi_systab_init(void *phys)
efi_systab.nr_tables = systab32->nr_tables;
efi_systab.tables = systab32->tables;
- early_iounmap(systab32, sizeof(*systab32));
+ early_memunmap(systab32, sizeof(*systab32));
}
efi.systab = &efi_systab;
@@ -586,7 +586,7 @@ static int __init efi_runtime_init(void)
* address of several of the EFI runtime functions, needed to
* set the firmware into virtual mode.
*/
- runtime = early_ioremap((unsigned long)efi.systab->runtime,
+ runtime = early_memremap((unsigned long)efi.systab->runtime,
sizeof(efi_runtime_services_t));
if (!runtime) {
pr_err("Could not map the runtime service table!\n");
@@ -606,7 +606,7 @@ static int __init efi_runtime_init(void)
* virtual mode.
*/
efi.get_time = phys_efi_get_time;
- early_iounmap(runtime, sizeof(efi_runtime_services_t));
+ early_memunmap(runtime, sizeof(efi_runtime_services_t));
return 0;
}
@@ -614,7 +614,7 @@ static int __init efi_runtime_init(void)
static int __init efi_memmap_init(void)
{
/* Map the EFI memory map */
- memmap.map = early_ioremap((unsigned long)memmap.phys_map,
+ memmap.map = early_memremap((unsigned long)memmap.phys_map,
memmap.nr_map * memmap.desc_size);
if (memmap.map == NULL) {
pr_err("Could not map the memory map!\n");
@@ -656,14 +656,14 @@ void __init efi_init(void)
/*
* Show what we know for posterity
*/
- c16 = tmp = early_ioremap(efi.systab->fw_vendor, 2);
+ c16 = tmp = early_memremap(efi.systab->fw_vendor, 2);
if (c16) {
for (i = 0; i < sizeof(vendor) - 1 && *c16; ++i)
vendor[i] = *c16++;
vendor[i] = '\0';
} else
pr_err("Could not map the firmware vendor!\n");
- early_iounmap(tmp, 2);
+ early_memunmap(tmp, 2);
pr_info("EFI v%u.%.02u by %s\n",
efi.systab->hdr.revision >> 16,
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2e2fbde..b716a66 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -253,7 +253,7 @@ int __init efi_config_init(efi_config_table_type_t *arch_tables)
if (table64 >> 32) {
pr_cont("\n");
pr_err("Table located above 4GB, disabling EFI.\n");
- early_iounmap(config_tables,
+ early_memunmap(config_tables,
efi.systab->nr_tables * sz);
return -EINVAL;
}
@@ -269,6 +269,6 @@ int __init efi_config_init(efi_config_table_type_t *arch_tables)
tablep += sz;
}
pr_cont("\n");
- early_iounmap(config_tables, efi.systab->nr_tables * sz);
+ early_memunmap(config_tables, efi.systab->nr_tables * sz);
return 0;
}
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-11 10:39 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 10:39 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, bp, greg, toshi.kani,
Leif Lindholm, Mark Salter
(Cc'ing Leif and Mark for the ARM-side of things)
On Mon, 09 Dec, at 05:42:15PM, Dave Young wrote:
> In arch/x86/platform/efi/efi.c and drivers/firmware/efi/efi.c turn to use
> early_memremap/early_memunmap instead of early_ioremap/early_iounmap so sparse
> will be happy.
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/platform/efi/efi.c | 20 ++++++++++----------
> drivers/firmware/efi/efi.c | 4 ++--
> 2 files changed, 12 insertions(+), 12 deletions(-)
This looks like a rather nice cleanup but the commit log could use a
little bit of tweaking...
- Please start your commit title (the part after the subsystem tag)
with a capital letter, e.g.
efi: Use early_memremap...
- You need to explain in the commit title that you're fixing a sparse
warning. Anyone reading the patch subject will have no idea _why_
you're using early_memremap() and early_memunmap().
- In the commit message body explain why sparse is currently unhappy.
Leif, Mark, does this patch look OK for ARM? We'd need to introduce a
new early_memunmap() function so that things still build, but that
should be straight forward. You'd even be able to get rid of the
asymmetry in uefi_init() where you map efi.systab with early_memremap()
but unmap it with early_iounmap().
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index f8ec4da..ef471d5 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -456,7 +456,7 @@ void __init efi_unmap_memmap(void)
> {
> clear_bit(EFI_MEMMAP, &x86_efi_facility);
> if (memmap.map) {
> - early_iounmap(memmap.map, memmap.nr_map * memmap.desc_size);
> + early_memunmap(memmap.map, memmap.nr_map * memmap.desc_size);
> memmap.map = NULL;
> }
> }
> @@ -493,7 +493,7 @@ static int __init efi_systab_init(void *phys)
> efi_system_table_64_t *systab64;
> u64 tmp = 0;
>
> - systab64 = early_ioremap((unsigned long)phys,
> + systab64 = early_memremap((unsigned long)phys,
> sizeof(*systab64));
> if (systab64 == NULL) {
> pr_err("Couldn't map the system table!\n");
> @@ -524,7 +524,7 @@ static int __init efi_systab_init(void *phys)
> efi_systab.tables = systab64->tables;
> tmp |= systab64->tables;
>
> - early_iounmap(systab64, sizeof(*systab64));
> + early_memunmap(systab64, sizeof(*systab64));
> #ifdef CONFIG_X86_32
> if (tmp >> 32) {
> pr_err("EFI data located above 4GB, disabling EFI.\n");
> @@ -534,7 +534,7 @@ static int __init efi_systab_init(void *phys)
> } else {
> efi_system_table_32_t *systab32;
>
> - systab32 = early_ioremap((unsigned long)phys,
> + systab32 = early_memremap((unsigned long)phys,
> sizeof(*systab32));
> if (systab32 == NULL) {
> pr_err("Couldn't map the system table!\n");
> @@ -555,7 +555,7 @@ static int __init efi_systab_init(void *phys)
> efi_systab.nr_tables = systab32->nr_tables;
> efi_systab.tables = systab32->tables;
>
> - early_iounmap(systab32, sizeof(*systab32));
> + early_memunmap(systab32, sizeof(*systab32));
> }
>
> efi.systab = &efi_systab;
> @@ -586,7 +586,7 @@ static int __init efi_runtime_init(void)
> * address of several of the EFI runtime functions, needed to
> * set the firmware into virtual mode.
> */
> - runtime = early_ioremap((unsigned long)efi.systab->runtime,
> + runtime = early_memremap((unsigned long)efi.systab->runtime,
> sizeof(efi_runtime_services_t));
> if (!runtime) {
> pr_err("Could not map the runtime service table!\n");
> @@ -606,7 +606,7 @@ static int __init efi_runtime_init(void)
> * virtual mode.
> */
> efi.get_time = phys_efi_get_time;
> - early_iounmap(runtime, sizeof(efi_runtime_services_t));
> + early_memunmap(runtime, sizeof(efi_runtime_services_t));
>
> return 0;
> }
> @@ -614,7 +614,7 @@ static int __init efi_runtime_init(void)
> static int __init efi_memmap_init(void)
> {
> /* Map the EFI memory map */
> - memmap.map = early_ioremap((unsigned long)memmap.phys_map,
> + memmap.map = early_memremap((unsigned long)memmap.phys_map,
> memmap.nr_map * memmap.desc_size);
> if (memmap.map == NULL) {
> pr_err("Could not map the memory map!\n");
> @@ -656,14 +656,14 @@ void __init efi_init(void)
> /*
> * Show what we know for posterity
> */
> - c16 = tmp = early_ioremap(efi.systab->fw_vendor, 2);
> + c16 = tmp = early_memremap(efi.systab->fw_vendor, 2);
> if (c16) {
> for (i = 0; i < sizeof(vendor) - 1 && *c16; ++i)
> vendor[i] = *c16++;
> vendor[i] = '\0';
> } else
> pr_err("Could not map the firmware vendor!\n");
> - early_iounmap(tmp, 2);
> + early_memunmap(tmp, 2);
>
> pr_info("EFI v%u.%.02u by %s\n",
> efi.systab->hdr.revision >> 16,
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 2e2fbde..b716a66 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -253,7 +253,7 @@ int __init efi_config_init(efi_config_table_type_t *arch_tables)
> if (table64 >> 32) {
> pr_cont("\n");
> pr_err("Table located above 4GB, disabling EFI.\n");
> - early_iounmap(config_tables,
> + early_memunmap(config_tables,
> efi.systab->nr_tables * sz);
> return -EINVAL;
> }
> @@ -269,6 +269,6 @@ int __init efi_config_init(efi_config_table_type_t *arch_tables)
> tablep += sz;
> }
> pr_cont("\n");
> - early_iounmap(config_tables, efi.systab->nr_tables * sz);
> + early_memunmap(config_tables, efi.systab->nr_tables * sz);
> return 0;
> }
> --
> 1.8.3.1
>
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-11 10:39 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 10:39 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, Mark Salter, linux-efi, toshi.kani, greg, x86, kexec,
linux-kernel, Leif Lindholm, James.Bottomley, horms, bp,
ebiederm, hpa, vgoyal
(Cc'ing Leif and Mark for the ARM-side of things)
On Mon, 09 Dec, at 05:42:15PM, Dave Young wrote:
> In arch/x86/platform/efi/efi.c and drivers/firmware/efi/efi.c turn to use
> early_memremap/early_memunmap instead of early_ioremap/early_iounmap so sparse
> will be happy.
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/platform/efi/efi.c | 20 ++++++++++----------
> drivers/firmware/efi/efi.c | 4 ++--
> 2 files changed, 12 insertions(+), 12 deletions(-)
This looks like a rather nice cleanup but the commit log could use a
little bit of tweaking...
- Please start your commit title (the part after the subsystem tag)
with a capital letter, e.g.
efi: Use early_memremap...
- You need to explain in the commit title that you're fixing a sparse
warning. Anyone reading the patch subject will have no idea _why_
you're using early_memremap() and early_memunmap().
- In the commit message body explain why sparse is currently unhappy.
Leif, Mark, does this patch look OK for ARM? We'd need to introduce a
new early_memunmap() function so that things still build, but that
should be straight forward. You'd even be able to get rid of the
asymmetry in uefi_init() where you map efi.systab with early_memremap()
but unmap it with early_iounmap().
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index f8ec4da..ef471d5 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -456,7 +456,7 @@ void __init efi_unmap_memmap(void)
> {
> clear_bit(EFI_MEMMAP, &x86_efi_facility);
> if (memmap.map) {
> - early_iounmap(memmap.map, memmap.nr_map * memmap.desc_size);
> + early_memunmap(memmap.map, memmap.nr_map * memmap.desc_size);
> memmap.map = NULL;
> }
> }
> @@ -493,7 +493,7 @@ static int __init efi_systab_init(void *phys)
> efi_system_table_64_t *systab64;
> u64 tmp = 0;
>
> - systab64 = early_ioremap((unsigned long)phys,
> + systab64 = early_memremap((unsigned long)phys,
> sizeof(*systab64));
> if (systab64 == NULL) {
> pr_err("Couldn't map the system table!\n");
> @@ -524,7 +524,7 @@ static int __init efi_systab_init(void *phys)
> efi_systab.tables = systab64->tables;
> tmp |= systab64->tables;
>
> - early_iounmap(systab64, sizeof(*systab64));
> + early_memunmap(systab64, sizeof(*systab64));
> #ifdef CONFIG_X86_32
> if (tmp >> 32) {
> pr_err("EFI data located above 4GB, disabling EFI.\n");
> @@ -534,7 +534,7 @@ static int __init efi_systab_init(void *phys)
> } else {
> efi_system_table_32_t *systab32;
>
> - systab32 = early_ioremap((unsigned long)phys,
> + systab32 = early_memremap((unsigned long)phys,
> sizeof(*systab32));
> if (systab32 == NULL) {
> pr_err("Couldn't map the system table!\n");
> @@ -555,7 +555,7 @@ static int __init efi_systab_init(void *phys)
> efi_systab.nr_tables = systab32->nr_tables;
> efi_systab.tables = systab32->tables;
>
> - early_iounmap(systab32, sizeof(*systab32));
> + early_memunmap(systab32, sizeof(*systab32));
> }
>
> efi.systab = &efi_systab;
> @@ -586,7 +586,7 @@ static int __init efi_runtime_init(void)
> * address of several of the EFI runtime functions, needed to
> * set the firmware into virtual mode.
> */
> - runtime = early_ioremap((unsigned long)efi.systab->runtime,
> + runtime = early_memremap((unsigned long)efi.systab->runtime,
> sizeof(efi_runtime_services_t));
> if (!runtime) {
> pr_err("Could not map the runtime service table!\n");
> @@ -606,7 +606,7 @@ static int __init efi_runtime_init(void)
> * virtual mode.
> */
> efi.get_time = phys_efi_get_time;
> - early_iounmap(runtime, sizeof(efi_runtime_services_t));
> + early_memunmap(runtime, sizeof(efi_runtime_services_t));
>
> return 0;
> }
> @@ -614,7 +614,7 @@ static int __init efi_runtime_init(void)
> static int __init efi_memmap_init(void)
> {
> /* Map the EFI memory map */
> - memmap.map = early_ioremap((unsigned long)memmap.phys_map,
> + memmap.map = early_memremap((unsigned long)memmap.phys_map,
> memmap.nr_map * memmap.desc_size);
> if (memmap.map == NULL) {
> pr_err("Could not map the memory map!\n");
> @@ -656,14 +656,14 @@ void __init efi_init(void)
> /*
> * Show what we know for posterity
> */
> - c16 = tmp = early_ioremap(efi.systab->fw_vendor, 2);
> + c16 = tmp = early_memremap(efi.systab->fw_vendor, 2);
> if (c16) {
> for (i = 0; i < sizeof(vendor) - 1 && *c16; ++i)
> vendor[i] = *c16++;
> vendor[i] = '\0';
> } else
> pr_err("Could not map the firmware vendor!\n");
> - early_iounmap(tmp, 2);
> + early_memunmap(tmp, 2);
>
> pr_info("EFI v%u.%.02u by %s\n",
> efi.systab->hdr.revision >> 16,
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 2e2fbde..b716a66 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -253,7 +253,7 @@ int __init efi_config_init(efi_config_table_type_t *arch_tables)
> if (table64 >> 32) {
> pr_cont("\n");
> pr_err("Table located above 4GB, disabling EFI.\n");
> - early_iounmap(config_tables,
> + early_memunmap(config_tables,
> efi.systab->nr_tables * sz);
> return -EINVAL;
> }
> @@ -269,6 +269,6 @@ int __init efi_config_init(efi_config_table_type_t *arch_tables)
> tablep += sz;
> }
> pr_cont("\n");
> - early_iounmap(config_tables, efi.systab->nr_tables * sz);
> + early_memunmap(config_tables, efi.systab->nr_tables * sz);
> return 0;
> }
> --
> 1.8.3.1
>
--
Matt Fleming, Intel Open Source Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-11 10:39 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 10:39 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bp-Gina5bIWoIWzQB+pC5nmwQ, greg-U8xfFu+wG4EAvxtiuMwx3w,
toshi.kani-VXdhtT5mjnY, Leif Lindholm, Mark Salter
(Cc'ing Leif and Mark for the ARM-side of things)
On Mon, 09 Dec, at 05:42:15PM, Dave Young wrote:
> In arch/x86/platform/efi/efi.c and drivers/firmware/efi/efi.c turn to use
> early_memremap/early_memunmap instead of early_ioremap/early_iounmap so sparse
> will be happy.
>
> Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> arch/x86/platform/efi/efi.c | 20 ++++++++++----------
> drivers/firmware/efi/efi.c | 4 ++--
> 2 files changed, 12 insertions(+), 12 deletions(-)
This looks like a rather nice cleanup but the commit log could use a
little bit of tweaking...
- Please start your commit title (the part after the subsystem tag)
with a capital letter, e.g.
efi: Use early_memremap...
- You need to explain in the commit title that you're fixing a sparse
warning. Anyone reading the patch subject will have no idea _why_
you're using early_memremap() and early_memunmap().
- In the commit message body explain why sparse is currently unhappy.
Leif, Mark, does this patch look OK for ARM? We'd need to introduce a
new early_memunmap() function so that things still build, but that
should be straight forward. You'd even be able to get rid of the
asymmetry in uefi_init() where you map efi.systab with early_memremap()
but unmap it with early_iounmap().
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index f8ec4da..ef471d5 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -456,7 +456,7 @@ void __init efi_unmap_memmap(void)
> {
> clear_bit(EFI_MEMMAP, &x86_efi_facility);
> if (memmap.map) {
> - early_iounmap(memmap.map, memmap.nr_map * memmap.desc_size);
> + early_memunmap(memmap.map, memmap.nr_map * memmap.desc_size);
> memmap.map = NULL;
> }
> }
> @@ -493,7 +493,7 @@ static int __init efi_systab_init(void *phys)
> efi_system_table_64_t *systab64;
> u64 tmp = 0;
>
> - systab64 = early_ioremap((unsigned long)phys,
> + systab64 = early_memremap((unsigned long)phys,
> sizeof(*systab64));
> if (systab64 == NULL) {
> pr_err("Couldn't map the system table!\n");
> @@ -524,7 +524,7 @@ static int __init efi_systab_init(void *phys)
> efi_systab.tables = systab64->tables;
> tmp |= systab64->tables;
>
> - early_iounmap(systab64, sizeof(*systab64));
> + early_memunmap(systab64, sizeof(*systab64));
> #ifdef CONFIG_X86_32
> if (tmp >> 32) {
> pr_err("EFI data located above 4GB, disabling EFI.\n");
> @@ -534,7 +534,7 @@ static int __init efi_systab_init(void *phys)
> } else {
> efi_system_table_32_t *systab32;
>
> - systab32 = early_ioremap((unsigned long)phys,
> + systab32 = early_memremap((unsigned long)phys,
> sizeof(*systab32));
> if (systab32 == NULL) {
> pr_err("Couldn't map the system table!\n");
> @@ -555,7 +555,7 @@ static int __init efi_systab_init(void *phys)
> efi_systab.nr_tables = systab32->nr_tables;
> efi_systab.tables = systab32->tables;
>
> - early_iounmap(systab32, sizeof(*systab32));
> + early_memunmap(systab32, sizeof(*systab32));
> }
>
> efi.systab = &efi_systab;
> @@ -586,7 +586,7 @@ static int __init efi_runtime_init(void)
> * address of several of the EFI runtime functions, needed to
> * set the firmware into virtual mode.
> */
> - runtime = early_ioremap((unsigned long)efi.systab->runtime,
> + runtime = early_memremap((unsigned long)efi.systab->runtime,
> sizeof(efi_runtime_services_t));
> if (!runtime) {
> pr_err("Could not map the runtime service table!\n");
> @@ -606,7 +606,7 @@ static int __init efi_runtime_init(void)
> * virtual mode.
> */
> efi.get_time = phys_efi_get_time;
> - early_iounmap(runtime, sizeof(efi_runtime_services_t));
> + early_memunmap(runtime, sizeof(efi_runtime_services_t));
>
> return 0;
> }
> @@ -614,7 +614,7 @@ static int __init efi_runtime_init(void)
> static int __init efi_memmap_init(void)
> {
> /* Map the EFI memory map */
> - memmap.map = early_ioremap((unsigned long)memmap.phys_map,
> + memmap.map = early_memremap((unsigned long)memmap.phys_map,
> memmap.nr_map * memmap.desc_size);
> if (memmap.map == NULL) {
> pr_err("Could not map the memory map!\n");
> @@ -656,14 +656,14 @@ void __init efi_init(void)
> /*
> * Show what we know for posterity
> */
> - c16 = tmp = early_ioremap(efi.systab->fw_vendor, 2);
> + c16 = tmp = early_memremap(efi.systab->fw_vendor, 2);
> if (c16) {
> for (i = 0; i < sizeof(vendor) - 1 && *c16; ++i)
> vendor[i] = *c16++;
> vendor[i] = '\0';
> } else
> pr_err("Could not map the firmware vendor!\n");
> - early_iounmap(tmp, 2);
> + early_memunmap(tmp, 2);
>
> pr_info("EFI v%u.%.02u by %s\n",
> efi.systab->hdr.revision >> 16,
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 2e2fbde..b716a66 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -253,7 +253,7 @@ int __init efi_config_init(efi_config_table_type_t *arch_tables)
> if (table64 >> 32) {
> pr_cont("\n");
> pr_err("Table located above 4GB, disabling EFI.\n");
> - early_iounmap(config_tables,
> + early_memunmap(config_tables,
> efi.systab->nr_tables * sz);
> return -EINVAL;
> }
> @@ -269,6 +269,6 @@ int __init efi_config_init(efi_config_table_type_t *arch_tables)
> tablep += sz;
> }
> pr_cont("\n");
> - early_iounmap(config_tables, efi.systab->nr_tables * sz);
> + early_memunmap(config_tables, efi.systab->nr_tables * sz);
> return 0;
> }
> --
> 1.8.3.1
>
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
2013-12-11 10:39 ` Matt Fleming
@ 2013-12-11 11:02 ` Leif Lindholm
-1 siblings, 0 replies; 183+ messages in thread
From: Leif Lindholm @ 2013-12-11 11:02 UTC (permalink / raw)
To: Matt Fleming
Cc: Dave Young, linux-kernel, linux-efi, x86, mjg59, hpa,
James.Bottomley, vgoyal, ebiederm, horms, kexec, bp, greg,
toshi.kani, Mark Salter
On Wed, Dec 11, 2013 at 10:39:03AM +0000, Matt Fleming wrote:
> Leif, Mark, does this patch look OK for ARM? We'd need to introduce a
> new early_memunmap() function so that things still build, but that
> should be straight forward. You'd even be able to get rid of the
> asymmetry in uefi_init() where you map efi.systab with early_memremap()
> but unmap it with early_iounmap().
This patch looks splendid for ARM. As long as Mark can get the new
function into an update to the early_*remap() set, I can include this
in my next version - which is coming this week.
/
Leif
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-11 11:02 ` Leif Lindholm
0 siblings, 0 replies; 183+ messages in thread
From: Leif Lindholm @ 2013-12-11 11:02 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59, Mark Salter, linux-efi, toshi.kani, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, bp, ebiederm, hpa,
Dave Young, vgoyal
On Wed, Dec 11, 2013 at 10:39:03AM +0000, Matt Fleming wrote:
> Leif, Mark, does this patch look OK for ARM? We'd need to introduce a
> new early_memunmap() function so that things still build, but that
> should be straight forward. You'd even be able to get rid of the
> asymmetry in uefi_init() where you map efi.systab with early_memremap()
> but unmap it with early_iounmap().
This patch looks splendid for ARM. As long as Mark can get the new
function into an update to the early_*remap() set, I can include this
in my next version - which is coming this week.
/
Leif
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-11 11:32 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 11:32 UTC (permalink / raw)
To: Leif Lindholm
Cc: Dave Young, linux-kernel, linux-efi, x86, mjg59, hpa,
James.Bottomley, vgoyal, ebiederm, horms, kexec, bp, greg,
toshi.kani, Mark Salter, Tony Luck
On Wed, 11 Dec, at 12:02:27PM, Leif Lindholm wrote:
> On Wed, Dec 11, 2013 at 10:39:03AM +0000, Matt Fleming wrote:
> > Leif, Mark, does this patch look OK for ARM? We'd need to introduce a
> > new early_memunmap() function so that things still build, but that
> > should be straight forward. You'd even be able to get rid of the
> > asymmetry in uefi_init() where you map efi.systab with early_memremap()
> > but unmap it with early_iounmap().
>
> This patch looks splendid for ARM. As long as Mark can get the new
> function into an update to the early_*remap() set, I can include this
> in my next version - which is coming this week.
Great!
Oh and ia64 would also need early_memunmap(). Tony, the original patch
is here,
http://article.gmane.org/gmane.linux.kernel.kexec/10383
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-11 11:32 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 11:32 UTC (permalink / raw)
To: Leif Lindholm
Cc: mjg59, Mark Salter, linux-efi, toshi.kani, greg, x86, kexec,
linux-kernel, Tony Luck, James.Bottomley, horms, bp, ebiederm,
hpa, Dave Young, vgoyal
On Wed, 11 Dec, at 12:02:27PM, Leif Lindholm wrote:
> On Wed, Dec 11, 2013 at 10:39:03AM +0000, Matt Fleming wrote:
> > Leif, Mark, does this patch look OK for ARM? We'd need to introduce a
> > new early_memunmap() function so that things still build, but that
> > should be straight forward. You'd even be able to get rid of the
> > asymmetry in uefi_init() where you map efi.systab with early_memremap()
> > but unmap it with early_iounmap().
>
> This patch looks splendid for ARM. As long as Mark can get the new
> function into an update to the early_*remap() set, I can include this
> in my next version - which is coming this week.
Great!
Oh and ia64 would also need early_memunmap(). Tony, the original patch
is here,
http://article.gmane.org/gmane.linux.kernel.kexec/10383
--
Matt Fleming, Intel Open Source Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-11 11:32 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 11:32 UTC (permalink / raw)
To: Leif Lindholm
Cc: Dave Young, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bp-Gina5bIWoIWzQB+pC5nmwQ, greg-U8xfFu+wG4EAvxtiuMwx3w,
toshi.kani-VXdhtT5mjnY, Mark Salter, Tony Luck
On Wed, 11 Dec, at 12:02:27PM, Leif Lindholm wrote:
> On Wed, Dec 11, 2013 at 10:39:03AM +0000, Matt Fleming wrote:
> > Leif, Mark, does this patch look OK for ARM? We'd need to introduce a
> > new early_memunmap() function so that things still build, but that
> > should be straight forward. You'd even be able to get rid of the
> > asymmetry in uefi_init() where you map efi.systab with early_memremap()
> > but unmap it with early_iounmap().
>
> This patch looks splendid for ARM. As long as Mark can get the new
> function into an update to the early_*remap() set, I can include this
> in my next version - which is coming this week.
Great!
Oh and ia64 would also need early_memunmap(). Tony, the original patch
is here,
http://article.gmane.org/gmane.linux.kernel.kexec/10383
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-11 15:17 ` Mark Salter
0 siblings, 0 replies; 183+ messages in thread
From: Mark Salter @ 2013-12-11 15:17 UTC (permalink / raw)
To: Matt Fleming
Cc: Leif Lindholm, Dave Young, linux-kernel, linux-efi, x86, mjg59,
hpa, James.Bottomley, vgoyal, ebiederm, horms, kexec, bp, greg,
toshi.kani, Tony Luck
On Wed, 2013-12-11 at 11:32 +0000, Matt Fleming wrote:
> On Wed, 11 Dec, at 12:02:27PM, Leif Lindholm wrote:
> > On Wed, Dec 11, 2013 at 10:39:03AM +0000, Matt Fleming wrote:
> > > Leif, Mark, does this patch look OK for ARM? We'd need to introduce a
> > > new early_memunmap() function so that things still build, but that
> > > should be straight forward. You'd even be able to get rid of the
> > > asymmetry in uefi_init() where you map efi.systab with early_memremap()
> > > but unmap it with early_iounmap().
> >
> > This patch looks splendid for ARM. As long as Mark can get the new
> > function into an update to the early_*remap() set, I can include this
> > in my next version - which is coming this week.
>
> Great!
>
> Oh and ia64 would also need early_memunmap(). Tony, the original patch
> is here,
>
Couldn't ia64 just do:
#define early_memremap(phys_addr, size) __va(phys_addr)
#define early_memunmap(addr, size)
Anyway, I posted a patch to create a generic early_ioremap
implementation using generic bits of the x86 code:
https://lkml.org/lkml/2013/11/27/621
So maybe Dave's patch 1/14 should be part of that series or
get rebased on top of it.
--Mark
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-11 15:17 ` Mark Salter
0 siblings, 0 replies; 183+ messages in thread
From: Mark Salter @ 2013-12-11 15:17 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59, linux-efi, toshi.kani, greg, x86, kexec, linux-kernel,
Leif Lindholm, Tony Luck, James.Bottomley, horms, bp, ebiederm,
hpa, Dave Young, vgoyal
On Wed, 2013-12-11 at 11:32 +0000, Matt Fleming wrote:
> On Wed, 11 Dec, at 12:02:27PM, Leif Lindholm wrote:
> > On Wed, Dec 11, 2013 at 10:39:03AM +0000, Matt Fleming wrote:
> > > Leif, Mark, does this patch look OK for ARM? We'd need to introduce a
> > > new early_memunmap() function so that things still build, but that
> > > should be straight forward. You'd even be able to get rid of the
> > > asymmetry in uefi_init() where you map efi.systab with early_memremap()
> > > but unmap it with early_iounmap().
> >
> > This patch looks splendid for ARM. As long as Mark can get the new
> > function into an update to the early_*remap() set, I can include this
> > in my next version - which is coming this week.
>
> Great!
>
> Oh and ia64 would also need early_memunmap(). Tony, the original patch
> is here,
>
Couldn't ia64 just do:
#define early_memremap(phys_addr, size) __va(phys_addr)
#define early_memunmap(addr, size)
Anyway, I posted a patch to create a generic early_ioremap
implementation using generic bits of the x86 code:
https://lkml.org/lkml/2013/11/27/621
So maybe Dave's patch 1/14 should be part of that series or
get rebased on top of it.
--Mark
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-11 15:17 ` Mark Salter
0 siblings, 0 replies; 183+ messages in thread
From: Mark Salter @ 2013-12-11 15:17 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, greg-U8xfFu+wG4EAvxtiuMwx3w,
x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leif Lindholm, Tony Luck,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
Dave Young, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On Wed, 2013-12-11 at 11:32 +0000, Matt Fleming wrote:
> On Wed, 11 Dec, at 12:02:27PM, Leif Lindholm wrote:
> > On Wed, Dec 11, 2013 at 10:39:03AM +0000, Matt Fleming wrote:
> > > Leif, Mark, does this patch look OK for ARM? We'd need to introduce a
> > > new early_memunmap() function so that things still build, but that
> > > should be straight forward. You'd even be able to get rid of the
> > > asymmetry in uefi_init() where you map efi.systab with early_memremap()
> > > but unmap it with early_iounmap().
> >
> > This patch looks splendid for ARM. As long as Mark can get the new
> > function into an update to the early_*remap() set, I can include this
> > in my next version - which is coming this week.
>
> Great!
>
> Oh and ia64 would also need early_memunmap(). Tony, the original patch
> is here,
>
Couldn't ia64 just do:
#define early_memremap(phys_addr, size) __va(phys_addr)
#define early_memunmap(addr, size)
Anyway, I posted a patch to create a generic early_ioremap
implementation using generic bits of the x86 code:
https://lkml.org/lkml/2013/11/27/621
So maybe Dave's patch 1/14 should be part of that series or
get rebased on top of it.
--Mark
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
2013-12-11 15:17 ` Mark Salter
@ 2013-12-13 15:51 ` Leif Lindholm
-1 siblings, 0 replies; 183+ messages in thread
From: Leif Lindholm @ 2013-12-13 15:51 UTC (permalink / raw)
To: Mark Salter
Cc: Matt Fleming, Dave Young, linux-kernel, linux-efi, x86, mjg59,
hpa, James.Bottomley, vgoyal, ebiederm, horms, kexec, bp, greg,
toshi.kani, Tony Luck
On Wed, Dec 11, 2013 at 10:17:58AM -0500, Mark Salter wrote:
> Anyway, I posted a patch to create a generic early_ioremap
> implementation using generic bits of the x86 code:
>
> https://lkml.org/lkml/2013/11/27/621
>
> So maybe Dave's patch 1/14 should be part of that series or
> get rebased on top of it.
Yes, having those two sets of changes to the same bits floating around
at the same time is painful.
If you could integrate those changes into your set, everyone wins.
/
Leif
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-13 15:51 ` Leif Lindholm
0 siblings, 0 replies; 183+ messages in thread
From: Leif Lindholm @ 2013-12-13 15:51 UTC (permalink / raw)
To: Mark Salter
Cc: Matt Fleming, linux-efi, toshi.kani, mjg59, greg, x86, kexec,
linux-kernel, Tony Luck, James.Bottomley, horms, bp, ebiederm,
hpa, Dave Young, vgoyal
On Wed, Dec 11, 2013 at 10:17:58AM -0500, Mark Salter wrote:
> Anyway, I posted a patch to create a generic early_ioremap
> implementation using generic bits of the x86 code:
>
> https://lkml.org/lkml/2013/11/27/621
>
> So maybe Dave's patch 1/14 should be part of that series or
> get rebased on top of it.
Yes, having those two sets of changes to the same bits floating around
at the same time is painful.
If you could integrate those changes into your set, everyone wins.
/
Leif
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-16 1:50 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 1:50 UTC (permalink / raw)
To: Leif Lindholm
Cc: Mark Salter, Matt Fleming, linux-kernel, linux-efi, x86, mjg59,
hpa, James.Bottomley, vgoyal, ebiederm, horms, kexec, bp, greg,
toshi.kani, Tony Luck
On 12/13/13 at 04:51pm, Leif Lindholm wrote:
> On Wed, Dec 11, 2013 at 10:17:58AM -0500, Mark Salter wrote:
> > Anyway, I posted a patch to create a generic early_ioremap
> > implementation using generic bits of the x86 code:
> >
> > https://lkml.org/lkml/2013/11/27/621
> >
> > So maybe Dave's patch 1/14 should be part of that series or
> > get rebased on top of it.
>
> Yes, having those two sets of changes to the same bits floating around
> at the same time is painful.
> If you could integrate those changes into your set, everyone wins.
I have no idea how to handle these dependency problems between different
patchset, but for this one I feel it's better to add it to Mark's series,
what's the status of the series, has it been reviewed and ready for merge?
--
Thanks
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-16 1:50 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 1:50 UTC (permalink / raw)
To: Leif Lindholm
Cc: Matt Fleming, linux-efi, hpa, mjg59, greg, x86, kexec,
linux-kernel, Tony Luck, James.Bottomley, horms, bp, ebiederm,
Mark Salter, toshi.kani, vgoyal
On 12/13/13 at 04:51pm, Leif Lindholm wrote:
> On Wed, Dec 11, 2013 at 10:17:58AM -0500, Mark Salter wrote:
> > Anyway, I posted a patch to create a generic early_ioremap
> > implementation using generic bits of the x86 code:
> >
> > https://lkml.org/lkml/2013/11/27/621
> >
> > So maybe Dave's patch 1/14 should be part of that series or
> > get rebased on top of it.
>
> Yes, having those two sets of changes to the same bits floating around
> at the same time is painful.
> If you could integrate those changes into your set, everyone wins.
I have no idea how to handle these dependency problems between different
patchset, but for this one I feel it's better to add it to Mark's series,
what's the status of the series, has it been reviewed and ready for merge?
--
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-16 1:50 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 1:50 UTC (permalink / raw)
To: Leif Lindholm
Cc: Matt Fleming, linux-efi-u79uwXL29TY76Z2rM5mHXA,
hpa-YMNOUZJC4hwAvxtiuMwx3w, mjg59-1xO5oi07KQx4cg9Nei1l7Q,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Tony Luck,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, Mark Salter,
toshi.kani-VXdhtT5mjnY, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On 12/13/13 at 04:51pm, Leif Lindholm wrote:
> On Wed, Dec 11, 2013 at 10:17:58AM -0500, Mark Salter wrote:
> > Anyway, I posted a patch to create a generic early_ioremap
> > implementation using generic bits of the x86 code:
> >
> > https://lkml.org/lkml/2013/11/27/621
> >
> > So maybe Dave's patch 1/14 should be part of that series or
> > get rebased on top of it.
>
> Yes, having those two sets of changes to the same bits floating around
> at the same time is painful.
> If you could integrate those changes into your set, everyone wins.
I have no idea how to handle these dependency problems between different
patchset, but for this one I feel it's better to add it to Mark's series,
what's the status of the series, has it been reviewed and ready for merge?
--
Thanks
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-12 2:04 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:04 UTC (permalink / raw)
To: Matt Fleming
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, bp, greg, toshi.kani,
Leif Lindholm, Mark Salter
On 12/11/13 at 10:39am, Matt Fleming wrote:
> (Cc'ing Leif and Mark for the ARM-side of things)
>
> On Mon, 09 Dec, at 05:42:15PM, Dave Young wrote:
> > In arch/x86/platform/efi/efi.c and drivers/firmware/efi/efi.c turn to use
> > early_memremap/early_memunmap instead of early_ioremap/early_iounmap so sparse
> > will be happy.
> >
> > Signed-off-by: Dave Young <dyoung@redhat.com>
> > ---
> > arch/x86/platform/efi/efi.c | 20 ++++++++++----------
> > drivers/firmware/efi/efi.c | 4 ++--
> > 2 files changed, 12 insertions(+), 12 deletions(-)
>
> This looks like a rather nice cleanup but the commit log could use a
> little bit of tweaking...
>
> - Please start your commit title (the part after the subsystem tag)
> with a capital letter, e.g.
>
> efi: Use early_memremap...
>
> - You need to explain in the commit title that you're fixing a sparse
> warning. Anyone reading the patch subject will have no idea _why_
> you're using early_memremap() and early_memunmap().
>
> - In the commit message body explain why sparse is currently unhappy.
Sure, will do.
--
Thanks for review
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-12 2:04 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:04 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59, Mark Salter, linux-efi, toshi.kani, greg, x86, kexec,
linux-kernel, Leif Lindholm, James.Bottomley, horms, bp,
ebiederm, hpa, vgoyal
On 12/11/13 at 10:39am, Matt Fleming wrote:
> (Cc'ing Leif and Mark for the ARM-side of things)
>
> On Mon, 09 Dec, at 05:42:15PM, Dave Young wrote:
> > In arch/x86/platform/efi/efi.c and drivers/firmware/efi/efi.c turn to use
> > early_memremap/early_memunmap instead of early_ioremap/early_iounmap so sparse
> > will be happy.
> >
> > Signed-off-by: Dave Young <dyoung@redhat.com>
> > ---
> > arch/x86/platform/efi/efi.c | 20 ++++++++++----------
> > drivers/firmware/efi/efi.c | 4 ++--
> > 2 files changed, 12 insertions(+), 12 deletions(-)
>
> This looks like a rather nice cleanup but the commit log could use a
> little bit of tweaking...
>
> - Please start your commit title (the part after the subsystem tag)
> with a capital letter, e.g.
>
> efi: Use early_memremap...
>
> - You need to explain in the commit title that you're fixing a sparse
> warning. Anyone reading the patch subject will have no idea _why_
> you're using early_memremap() and early_memunmap().
>
> - In the commit message body explain why sparse is currently unhappy.
Sure, will do.
--
Thanks for review
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-12 2:04 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:04 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, Mark Salter,
linux-efi-u79uwXL29TY76Z2rM5mHXA, toshi.kani-VXdhtT5mjnY,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Leif Lindholm,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On 12/11/13 at 10:39am, Matt Fleming wrote:
> (Cc'ing Leif and Mark for the ARM-side of things)
>
> On Mon, 09 Dec, at 05:42:15PM, Dave Young wrote:
> > In arch/x86/platform/efi/efi.c and drivers/firmware/efi/efi.c turn to use
> > early_memremap/early_memunmap instead of early_ioremap/early_iounmap so sparse
> > will be happy.
> >
> > Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > ---
> > arch/x86/platform/efi/efi.c | 20 ++++++++++----------
> > drivers/firmware/efi/efi.c | 4 ++--
> > 2 files changed, 12 insertions(+), 12 deletions(-)
>
> This looks like a rather nice cleanup but the commit log could use a
> little bit of tweaking...
>
> - Please start your commit title (the part after the subsystem tag)
> with a capital letter, e.g.
>
> efi: Use early_memremap...
>
> - You need to explain in the commit title that you're fixing a sparse
> warning. Anyone reading the patch subject will have no idea _why_
> you're using early_memremap() and early_memunmap().
>
> - In the commit message body explain why sparse is currently unhappy.
Sure, will do.
--
Thanks for review
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-11 17:38 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 17:38 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On Mon, Dec 09, 2013 at 05:42:15PM +0800, Dave Young wrote:
> In arch/x86/platform/efi/efi.c and drivers/firmware/efi/efi.c turn to use
> early_memremap/early_memunmap instead of early_ioremap/early_iounmap so sparse
> will be happy.
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-11 17:38 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 17:38 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On Mon, Dec 09, 2013 at 05:42:15PM +0800, Dave Young wrote:
> In arch/x86/platform/efi/efi.c and drivers/firmware/efi/efi.c turn to use
> early_memremap/early_memunmap instead of early_ioremap/early_iounmap so sparse
> will be happy.
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 02/14] efi: use early_memremap and early_memunmap
@ 2013-12-11 17:38 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 17:38 UTC (permalink / raw)
To: Dave Young
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
hpa-YMNOUZJC4hwAvxtiuMwx3w, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On Mon, Dec 09, 2013 at 05:42:15PM +0800, Dave Young wrote:
> In arch/x86/platform/efi/efi.c and drivers/firmware/efi/efi.c turn to use
> early_memremap/early_memunmap instead of early_ioremap/early_iounmap so sparse
> will be happy.
>
> Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Acked-by: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH v5 03/14] efi: remove unused variables in __map_region
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
variables size and end is useless in this function, thus remove them.
Reported-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
---
arch/x86/platform/efi/efi_64.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index bf286c3..c5a6491 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -148,15 +148,11 @@ void efi_setup_page_tables(void)
static void __init __map_region(efi_memory_desc_t *md, u64 va)
{
pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
- unsigned long pf = 0, size;
- u64 end;
+ unsigned long pf = 0;
if (!(md->attribute & EFI_MEMORY_WB))
pf |= _PAGE_PCD;
- size = md->num_pages << PAGE_SHIFT;
- end = va + size;
-
if (kernel_map_pages_in_pgd(pgd, md->phys_addr, va, md->num_pages, pf))
pr_warn("Error mapping PA 0x%llx -> VA 0x%llx!\n",
md->phys_addr, va);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 03/14] efi: remove unused variables in __map_region
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
variables size and end is useless in this function, thus remove them.
Reported-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
---
arch/x86/platform/efi/efi_64.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index bf286c3..c5a6491 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -148,15 +148,11 @@ void efi_setup_page_tables(void)
static void __init __map_region(efi_memory_desc_t *md, u64 va)
{
pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
- unsigned long pf = 0, size;
- u64 end;
+ unsigned long pf = 0;
if (!(md->attribute & EFI_MEMORY_WB))
pf |= _PAGE_PCD;
- size = md->num_pages << PAGE_SHIFT;
- end = va + size;
-
if (kernel_map_pages_in_pgd(pgd, md->phys_addr, va, md->num_pages, pf))
pr_warn("Error mapping PA 0x%llx -> VA 0x%llx!\n",
md->phys_addr, va);
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 03/14] efi: remove unused variables in __map_region
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
variables size and end is useless in this function, thus remove them.
Reported-by: Toshi Kani <toshi.kani-VXdhtT5mjnY@public.gmane.org>
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Acked-by: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>
---
arch/x86/platform/efi/efi_64.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index bf286c3..c5a6491 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -148,15 +148,11 @@ void efi_setup_page_tables(void)
static void __init __map_region(efi_memory_desc_t *md, u64 va)
{
pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
- unsigned long pf = 0, size;
- u64 end;
+ unsigned long pf = 0;
if (!(md->attribute & EFI_MEMORY_WB))
pf |= _PAGE_PCD;
- size = md->num_pages << PAGE_SHIFT;
- end = va + size;
-
if (kernel_map_pages_in_pgd(pgd, md->phys_addr, va, md->num_pages, pf))
pr_warn("Error mapping PA 0x%llx -> VA 0x%llx!\n",
md->phys_addr, va);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH v5 04/14] efi: add a wrapper function efi_map_region_fixed
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_map_region_fixed for directly mapping a md
to md->virt.
The md is passed in from 1st kernel, the virtual addr is
saved in md->virt_addr.
Matt: coding style
reuse __map_region
Boris: Strenthen comment lines to 80 cols.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
---
arch/x86/include/asm/efi.h | 1 +
arch/x86/platform/efi/efi_32.c | 2 ++
arch/x86/platform/efi/efi_64.c | 10 ++++++++++
3 files changed, 13 insertions(+)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 89a05b0..9fbaeb2 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -128,6 +128,7 @@ extern void efi_call_phys_epilog(void);
extern void efi_unmap_memmap(void);
extern void efi_memory_uc(u64 addr, unsigned long size);
extern void __init efi_map_region(efi_memory_desc_t *md);
+extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
extern void efi_sync_low_kernel_mappings(void);
extern void efi_setup_page_tables(void);
extern void __init old_map_region(efi_memory_desc_t *md);
diff --git a/arch/x86/platform/efi/efi_32.c b/arch/x86/platform/efi/efi_32.c
index e94557c..7b3ec6e 100644
--- a/arch/x86/platform/efi/efi_32.c
+++ b/arch/x86/platform/efi/efi_32.c
@@ -47,6 +47,8 @@ void __init efi_map_region(efi_memory_desc_t *md)
old_map_region(md);
}
+void __init efi_map_region_fixed(efi_memory_desc_t *md) {}
+
void efi_call_phys_prelog(void)
{
struct desc_ptr gdt_descr;
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index c5a6491..ff08cb1 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -199,6 +199,16 @@ void __init efi_map_region(efi_memory_desc_t *md)
md->virt_addr = efi_va;
}
+/*
+ * kexec kernel will use efi_map_region_fixed to map efi runtime memory ranges.
+ * md->virt_addr is the original virtual address which had been mapped in kexec
+ * 1st kernel.
+ */
+void __init efi_map_region_fixed(efi_memory_desc_t *md)
+{
+ __map_region(md, md->virt_addr);
+}
+
void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
u32 type, u64 attribute)
{
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 04/14] efi: add a wrapper function efi_map_region_fixed
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_map_region_fixed for directly mapping a md
to md->virt.
The md is passed in from 1st kernel, the virtual addr is
saved in md->virt_addr.
Matt: coding style
reuse __map_region
Boris: Strenthen comment lines to 80 cols.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
---
arch/x86/include/asm/efi.h | 1 +
arch/x86/platform/efi/efi_32.c | 2 ++
arch/x86/platform/efi/efi_64.c | 10 ++++++++++
3 files changed, 13 insertions(+)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 89a05b0..9fbaeb2 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -128,6 +128,7 @@ extern void efi_call_phys_epilog(void);
extern void efi_unmap_memmap(void);
extern void efi_memory_uc(u64 addr, unsigned long size);
extern void __init efi_map_region(efi_memory_desc_t *md);
+extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
extern void efi_sync_low_kernel_mappings(void);
extern void efi_setup_page_tables(void);
extern void __init old_map_region(efi_memory_desc_t *md);
diff --git a/arch/x86/platform/efi/efi_32.c b/arch/x86/platform/efi/efi_32.c
index e94557c..7b3ec6e 100644
--- a/arch/x86/platform/efi/efi_32.c
+++ b/arch/x86/platform/efi/efi_32.c
@@ -47,6 +47,8 @@ void __init efi_map_region(efi_memory_desc_t *md)
old_map_region(md);
}
+void __init efi_map_region_fixed(efi_memory_desc_t *md) {}
+
void efi_call_phys_prelog(void)
{
struct desc_ptr gdt_descr;
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index c5a6491..ff08cb1 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -199,6 +199,16 @@ void __init efi_map_region(efi_memory_desc_t *md)
md->virt_addr = efi_va;
}
+/*
+ * kexec kernel will use efi_map_region_fixed to map efi runtime memory ranges.
+ * md->virt_addr is the original virtual address which had been mapped in kexec
+ * 1st kernel.
+ */
+void __init efi_map_region_fixed(efi_memory_desc_t *md)
+{
+ __map_region(md, md->virt_addr);
+}
+
void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
u32 type, u64 attribute)
{
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 04/14] efi: add a wrapper function efi_map_region_fixed
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_map_region_fixed for directly mapping a md
to md->virt.
The md is passed in from 1st kernel, the virtual addr is
saved in md->virt_addr.
Matt: coding style
reuse __map_region
Boris: Strenthen comment lines to 80 cols.
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Acked-by: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>
---
arch/x86/include/asm/efi.h | 1 +
arch/x86/platform/efi/efi_32.c | 2 ++
arch/x86/platform/efi/efi_64.c | 10 ++++++++++
3 files changed, 13 insertions(+)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 89a05b0..9fbaeb2 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -128,6 +128,7 @@ extern void efi_call_phys_epilog(void);
extern void efi_unmap_memmap(void);
extern void efi_memory_uc(u64 addr, unsigned long size);
extern void __init efi_map_region(efi_memory_desc_t *md);
+extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
extern void efi_sync_low_kernel_mappings(void);
extern void efi_setup_page_tables(void);
extern void __init old_map_region(efi_memory_desc_t *md);
diff --git a/arch/x86/platform/efi/efi_32.c b/arch/x86/platform/efi/efi_32.c
index e94557c..7b3ec6e 100644
--- a/arch/x86/platform/efi/efi_32.c
+++ b/arch/x86/platform/efi/efi_32.c
@@ -47,6 +47,8 @@ void __init efi_map_region(efi_memory_desc_t *md)
old_map_region(md);
}
+void __init efi_map_region_fixed(efi_memory_desc_t *md) {}
+
void efi_call_phys_prelog(void)
{
struct desc_ptr gdt_descr;
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index c5a6491..ff08cb1 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -199,6 +199,16 @@ void __init efi_map_region(efi_memory_desc_t *md)
md->virt_addr = efi_va;
}
+/*
+ * kexec kernel will use efi_map_region_fixed to map efi runtime memory ranges.
+ * md->virt_addr is the original virtual address which had been mapped in kexec
+ * 1st kernel.
+ */
+void __init efi_map_region_fixed(efi_memory_desc_t *md)
+{
+ __map_region(md, md->virt_addr);
+}
+
void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
u32 type, u64 attribute)
{
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH v5 05/14] efi: reserve boot service fix
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
Current code check boot service region with kernel text region by:
start+size >= __pa_symbol(_text)
The end of the above region should be start + size - 1 instead.
I see this problem in ovmf + Fedora 19 grub boot:
text start: 1000000 md start: 800000 md size: 800000
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Toshi Kani <toshi.kani@hp.com>
---
arch/x86/platform/efi/efi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index ef471d5..8a88c68 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -438,7 +438,7 @@ void __init efi_reserve_boot_services(void)
* - Not within any part of the kernel
* - Not the bios reserved area
*/
- if ((start+size >= __pa_symbol(_text)
+ if ((start + size > __pa_symbol(_text)
&& start <= __pa_symbol(_end)) ||
!e820_all_mapped(start, start+size, E820_RAM) ||
memblock_is_region_reserved(start, size)) {
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 05/14] efi: reserve boot service fix
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
Current code check boot service region with kernel text region by:
start+size >= __pa_symbol(_text)
The end of the above region should be start + size - 1 instead.
I see this problem in ovmf + Fedora 19 grub boot:
text start: 1000000 md start: 800000 md size: 800000
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Toshi Kani <toshi.kani@hp.com>
---
arch/x86/platform/efi/efi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index ef471d5..8a88c68 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -438,7 +438,7 @@ void __init efi_reserve_boot_services(void)
* - Not within any part of the kernel
* - Not the bios reserved area
*/
- if ((start+size >= __pa_symbol(_text)
+ if ((start + size > __pa_symbol(_text)
&& start <= __pa_symbol(_end)) ||
!e820_all_mapped(start, start+size, E820_RAM) ||
memblock_is_region_reserved(start, size)) {
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 05/14] efi: reserve boot service fix
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
Current code check boot service region with kernel text region by:
start+size >= __pa_symbol(_text)
The end of the above region should be start + size - 1 instead.
I see this problem in ovmf + Fedora 19 grub boot:
text start: 1000000 md start: 800000 md size: 800000
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Acked-by: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>
Acked-by: Toshi Kani <toshi.kani-VXdhtT5mjnY@public.gmane.org>
---
arch/x86/platform/efi/efi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index ef471d5..8a88c68 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -438,7 +438,7 @@ void __init efi_reserve_boot_services(void)
* - Not within any part of the kernel
* - Not the bios reserved area
*/
- if ((start+size >= __pa_symbol(_text)
+ if ((start + size > __pa_symbol(_text)
&& start <= __pa_symbol(_end)) ||
!e820_all_mapped(start, start+size, E820_RAM) ||
memblock_is_region_reserved(start, size)) {
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH v5 06/14] efi: cleanup efi_enter_virtual_mode function
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.
v1->v2:
refresh; coding style fixes.
v2->v3:
Toshi Kani:
remove unused variable
Matt: check return value of krealloc.
v3->v4:
Boris: Stretch comment to 80 cols
fix krealloc bug.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
---
arch/x86/platform/efi/efi.c | 123 ++++++++++++++++++++++++++------------------
1 file changed, 72 insertions(+), 51 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 8a88c68..7778b5f 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -773,44 +773,12 @@ void __init old_map_region(efi_memory_desc_t *md)
(unsigned long long)md->phys_addr);
}
-/*
- * This function will switch the EFI runtime services to virtual mode.
- * Essentially, we look through the EFI memmap and map every region that
- * has the runtime attribute bit set in its memory descriptor into the
- * ->trampoline_pgd page table using a top-down VA allocation scheme.
- *
- * The old method which used to update that memory descriptor with the
- * virtual address obtained from ioremap() is still supported when the
- * kernel is booted with efi=old_map on its command line. Same old
- * method enabled the runtime services to be called without having to
- * thunk back into physical mode for every invocation.
- *
- * The new method does a pagetable switch in a preemption-safe manner
- * so that we're in a different address space when calling a runtime
- * function. For function arguments passing we do copy the PGDs of the
- * kernel page table into ->trampoline_pgd prior to each call.
- */
-void __init efi_enter_virtual_mode(void)
+/* Merge contiguous regions of the same type and attribute */
+static void __init efi_merge_regions(void)
{
+ void *p;
efi_memory_desc_t *md, *prev_md = NULL;
- void *p, *new_memmap = NULL;
- unsigned long size;
- efi_status_t status;
- u64 end, systab;
- int count = 0;
-
- efi.systab = NULL;
-
- /*
- * We don't do virtual mode, since we don't do runtime services, on
- * non-native EFI
- */
- if (!efi_is_native()) {
- efi_unmap_memmap();
- return;
- }
- /* Merge contiguous regions of the same type and attribute */
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
u64 prev_size;
md = p;
@@ -835,8 +803,19 @@ void __init efi_enter_virtual_mode(void)
continue;
}
prev_md = md;
-
}
+}
+
+/*
+ * Map efi memory ranges for runtime serivce and update new_memmap with virtual
+ * addresses.
+ */
+static void * __init efi_map_regions(int *count)
+{
+ efi_memory_desc_t *md;
+ void *p, *tmp, *new_memmap = NULL;
+ unsigned long size;
+ u64 end, systab;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
@@ -852,23 +831,68 @@ void __init efi_enter_virtual_mode(void)
size = md->num_pages << EFI_PAGE_SHIFT;
end = md->phys_addr + size;
-
- systab = (u64) (unsigned long) efi_phys.systab;
+ systab = (u64)(unsigned long)efi_phys.systab;
if (md->phys_addr <= systab && systab < end) {
systab += md->virt_addr - md->phys_addr;
-
- efi.systab = (efi_system_table_t *) (unsigned long) systab;
+ efi.systab = (efi_system_table_t *)(unsigned long)systab;
}
- new_memmap = krealloc(new_memmap,
- (count + 1) * memmap.desc_size,
- GFP_KERNEL);
- if (!new_memmap)
- goto err_out;
-
- memcpy(new_memmap + (count * memmap.desc_size), md,
+ tmp = krealloc(new_memmap, (*count + 1) * memmap.desc_size,
+ GFP_KERNEL);
+ if (!tmp)
+ goto out_krealloc;
+ new_memmap = tmp;
+ memcpy(new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
- count++;
+ (*count)++;
+ }
+
+ return new_memmap;
+out_krealloc:
+ kfree(new_memmap);
+ return NULL;
+}
+
+/*
+ * This function will switch the EFI runtime services to virtual mode.
+ * Essentially, we look through the EFI memmap and map every region that
+ * has the runtime attribute bit set in its memory descriptor into the
+ * ->trampoline_pgd page table using a top-down VA allocation scheme.
+ *
+ * The old method which used to update that memory descriptor with the
+ * virtual address obtained from ioremap() is still supported when the
+ * kernel is booted with efi=old_map on its command line. Same old
+ * method enabled the runtime services to be called without having to
+ * thunk back into physical mode for every invocation.
+ *
+ * The new method does a pagetable switch in a preemption-safe manner
+ * so that we're in a different address space when calling a runtime
+ * function. For function arguments passing we do copy the PGDs of the
+ * kernel page table into ->trampoline_pgd prior to each call.
+ */
+void __init efi_enter_virtual_mode(void)
+{
+ efi_status_t status;
+ void *new_memmap = NULL;
+ int count = 0;
+
+ efi.systab = NULL;
+
+ /*
+ * We don't do virtual mode, since we don't do runtime services, on
+ * non-native EFI
+ */
+ if (!efi_is_native()) {
+ efi_unmap_memmap();
+ return;
+ }
+
+ efi_merge_regions();
+
+ new_memmap = efi_map_regions(&count);
+ if (!new_memmap) {
+ pr_err("Error reallocating memory, EFI runtime non-functional!\n");
+ return;
}
BUG_ON(!efi.systab);
@@ -922,9 +946,6 @@ void __init efi_enter_virtual_mode(void)
0, NULL);
return;
-
- err_out:
- pr_err("Error reallocating memory, EFI runtime non-functional!\n");
}
/*
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 06/14] efi: cleanup efi_enter_virtual_mode function
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.
v1->v2:
refresh; coding style fixes.
v2->v3:
Toshi Kani:
remove unused variable
Matt: check return value of krealloc.
v3->v4:
Boris: Stretch comment to 80 cols
fix krealloc bug.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
---
arch/x86/platform/efi/efi.c | 123 ++++++++++++++++++++++++++------------------
1 file changed, 72 insertions(+), 51 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 8a88c68..7778b5f 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -773,44 +773,12 @@ void __init old_map_region(efi_memory_desc_t *md)
(unsigned long long)md->phys_addr);
}
-/*
- * This function will switch the EFI runtime services to virtual mode.
- * Essentially, we look through the EFI memmap and map every region that
- * has the runtime attribute bit set in its memory descriptor into the
- * ->trampoline_pgd page table using a top-down VA allocation scheme.
- *
- * The old method which used to update that memory descriptor with the
- * virtual address obtained from ioremap() is still supported when the
- * kernel is booted with efi=old_map on its command line. Same old
- * method enabled the runtime services to be called without having to
- * thunk back into physical mode for every invocation.
- *
- * The new method does a pagetable switch in a preemption-safe manner
- * so that we're in a different address space when calling a runtime
- * function. For function arguments passing we do copy the PGDs of the
- * kernel page table into ->trampoline_pgd prior to each call.
- */
-void __init efi_enter_virtual_mode(void)
+/* Merge contiguous regions of the same type and attribute */
+static void __init efi_merge_regions(void)
{
+ void *p;
efi_memory_desc_t *md, *prev_md = NULL;
- void *p, *new_memmap = NULL;
- unsigned long size;
- efi_status_t status;
- u64 end, systab;
- int count = 0;
-
- efi.systab = NULL;
-
- /*
- * We don't do virtual mode, since we don't do runtime services, on
- * non-native EFI
- */
- if (!efi_is_native()) {
- efi_unmap_memmap();
- return;
- }
- /* Merge contiguous regions of the same type and attribute */
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
u64 prev_size;
md = p;
@@ -835,8 +803,19 @@ void __init efi_enter_virtual_mode(void)
continue;
}
prev_md = md;
-
}
+}
+
+/*
+ * Map efi memory ranges for runtime serivce and update new_memmap with virtual
+ * addresses.
+ */
+static void * __init efi_map_regions(int *count)
+{
+ efi_memory_desc_t *md;
+ void *p, *tmp, *new_memmap = NULL;
+ unsigned long size;
+ u64 end, systab;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
@@ -852,23 +831,68 @@ void __init efi_enter_virtual_mode(void)
size = md->num_pages << EFI_PAGE_SHIFT;
end = md->phys_addr + size;
-
- systab = (u64) (unsigned long) efi_phys.systab;
+ systab = (u64)(unsigned long)efi_phys.systab;
if (md->phys_addr <= systab && systab < end) {
systab += md->virt_addr - md->phys_addr;
-
- efi.systab = (efi_system_table_t *) (unsigned long) systab;
+ efi.systab = (efi_system_table_t *)(unsigned long)systab;
}
- new_memmap = krealloc(new_memmap,
- (count + 1) * memmap.desc_size,
- GFP_KERNEL);
- if (!new_memmap)
- goto err_out;
-
- memcpy(new_memmap + (count * memmap.desc_size), md,
+ tmp = krealloc(new_memmap, (*count + 1) * memmap.desc_size,
+ GFP_KERNEL);
+ if (!tmp)
+ goto out_krealloc;
+ new_memmap = tmp;
+ memcpy(new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
- count++;
+ (*count)++;
+ }
+
+ return new_memmap;
+out_krealloc:
+ kfree(new_memmap);
+ return NULL;
+}
+
+/*
+ * This function will switch the EFI runtime services to virtual mode.
+ * Essentially, we look through the EFI memmap and map every region that
+ * has the runtime attribute bit set in its memory descriptor into the
+ * ->trampoline_pgd page table using a top-down VA allocation scheme.
+ *
+ * The old method which used to update that memory descriptor with the
+ * virtual address obtained from ioremap() is still supported when the
+ * kernel is booted with efi=old_map on its command line. Same old
+ * method enabled the runtime services to be called without having to
+ * thunk back into physical mode for every invocation.
+ *
+ * The new method does a pagetable switch in a preemption-safe manner
+ * so that we're in a different address space when calling a runtime
+ * function. For function arguments passing we do copy the PGDs of the
+ * kernel page table into ->trampoline_pgd prior to each call.
+ */
+void __init efi_enter_virtual_mode(void)
+{
+ efi_status_t status;
+ void *new_memmap = NULL;
+ int count = 0;
+
+ efi.systab = NULL;
+
+ /*
+ * We don't do virtual mode, since we don't do runtime services, on
+ * non-native EFI
+ */
+ if (!efi_is_native()) {
+ efi_unmap_memmap();
+ return;
+ }
+
+ efi_merge_regions();
+
+ new_memmap = efi_map_regions(&count);
+ if (!new_memmap) {
+ pr_err("Error reallocating memory, EFI runtime non-functional!\n");
+ return;
}
BUG_ON(!efi.systab);
@@ -922,9 +946,6 @@ void __init efi_enter_virtual_mode(void)
0, NULL);
return;
-
- err_out:
- pr_err("Error reallocating memory, EFI runtime non-functional!\n");
}
/*
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 06/14] efi: cleanup efi_enter_virtual_mode function
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.
v1->v2:
refresh; coding style fixes.
v2->v3:
Toshi Kani:
remove unused variable
Matt: check return value of krealloc.
v3->v4:
Boris: Stretch comment to 80 cols
fix krealloc bug.
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Acked-by: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>
---
arch/x86/platform/efi/efi.c | 123 ++++++++++++++++++++++++++------------------
1 file changed, 72 insertions(+), 51 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 8a88c68..7778b5f 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -773,44 +773,12 @@ void __init old_map_region(efi_memory_desc_t *md)
(unsigned long long)md->phys_addr);
}
-/*
- * This function will switch the EFI runtime services to virtual mode.
- * Essentially, we look through the EFI memmap and map every region that
- * has the runtime attribute bit set in its memory descriptor into the
- * ->trampoline_pgd page table using a top-down VA allocation scheme.
- *
- * The old method which used to update that memory descriptor with the
- * virtual address obtained from ioremap() is still supported when the
- * kernel is booted with efi=old_map on its command line. Same old
- * method enabled the runtime services to be called without having to
- * thunk back into physical mode for every invocation.
- *
- * The new method does a pagetable switch in a preemption-safe manner
- * so that we're in a different address space when calling a runtime
- * function. For function arguments passing we do copy the PGDs of the
- * kernel page table into ->trampoline_pgd prior to each call.
- */
-void __init efi_enter_virtual_mode(void)
+/* Merge contiguous regions of the same type and attribute */
+static void __init efi_merge_regions(void)
{
+ void *p;
efi_memory_desc_t *md, *prev_md = NULL;
- void *p, *new_memmap = NULL;
- unsigned long size;
- efi_status_t status;
- u64 end, systab;
- int count = 0;
-
- efi.systab = NULL;
-
- /*
- * We don't do virtual mode, since we don't do runtime services, on
- * non-native EFI
- */
- if (!efi_is_native()) {
- efi_unmap_memmap();
- return;
- }
- /* Merge contiguous regions of the same type and attribute */
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
u64 prev_size;
md = p;
@@ -835,8 +803,19 @@ void __init efi_enter_virtual_mode(void)
continue;
}
prev_md = md;
-
}
+}
+
+/*
+ * Map efi memory ranges for runtime serivce and update new_memmap with virtual
+ * addresses.
+ */
+static void * __init efi_map_regions(int *count)
+{
+ efi_memory_desc_t *md;
+ void *p, *tmp, *new_memmap = NULL;
+ unsigned long size;
+ u64 end, systab;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
@@ -852,23 +831,68 @@ void __init efi_enter_virtual_mode(void)
size = md->num_pages << EFI_PAGE_SHIFT;
end = md->phys_addr + size;
-
- systab = (u64) (unsigned long) efi_phys.systab;
+ systab = (u64)(unsigned long)efi_phys.systab;
if (md->phys_addr <= systab && systab < end) {
systab += md->virt_addr - md->phys_addr;
-
- efi.systab = (efi_system_table_t *) (unsigned long) systab;
+ efi.systab = (efi_system_table_t *)(unsigned long)systab;
}
- new_memmap = krealloc(new_memmap,
- (count + 1) * memmap.desc_size,
- GFP_KERNEL);
- if (!new_memmap)
- goto err_out;
-
- memcpy(new_memmap + (count * memmap.desc_size), md,
+ tmp = krealloc(new_memmap, (*count + 1) * memmap.desc_size,
+ GFP_KERNEL);
+ if (!tmp)
+ goto out_krealloc;
+ new_memmap = tmp;
+ memcpy(new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
- count++;
+ (*count)++;
+ }
+
+ return new_memmap;
+out_krealloc:
+ kfree(new_memmap);
+ return NULL;
+}
+
+/*
+ * This function will switch the EFI runtime services to virtual mode.
+ * Essentially, we look through the EFI memmap and map every region that
+ * has the runtime attribute bit set in its memory descriptor into the
+ * ->trampoline_pgd page table using a top-down VA allocation scheme.
+ *
+ * The old method which used to update that memory descriptor with the
+ * virtual address obtained from ioremap() is still supported when the
+ * kernel is booted with efi=old_map on its command line. Same old
+ * method enabled the runtime services to be called without having to
+ * thunk back into physical mode for every invocation.
+ *
+ * The new method does a pagetable switch in a preemption-safe manner
+ * so that we're in a different address space when calling a runtime
+ * function. For function arguments passing we do copy the PGDs of the
+ * kernel page table into ->trampoline_pgd prior to each call.
+ */
+void __init efi_enter_virtual_mode(void)
+{
+ efi_status_t status;
+ void *new_memmap = NULL;
+ int count = 0;
+
+ efi.systab = NULL;
+
+ /*
+ * We don't do virtual mode, since we don't do runtime services, on
+ * non-native EFI
+ */
+ if (!efi_is_native()) {
+ efi_unmap_memmap();
+ return;
+ }
+
+ efi_merge_regions();
+
+ new_memmap = efi_map_regions(&count);
+ if (!new_memmap) {
+ pr_err("Error reallocating memory, EFI runtime non-functional!\n");
+ return;
}
BUG_ON(!efi.systab);
@@ -922,9 +946,6 @@ void __init efi_enter_virtual_mode(void)
0, NULL);
return;
-
- err_out:
- pr_err("Error reallocating memory, EFI runtime non-functional!\n");
}
/*
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH v5 07/14] efi: export more efi table variable to sysfs
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
Export fw_vendor, runtime and config table physical addresses to
/sys/firmware/efi/fw_vendor, /sys/firmware/efi/runtime and
/sys/firmware/efi/config_table because kexec kernel will need them.
>From EFI spec these 3 variables will be updated to
virtual address after entering virtual mode. But
kernel startup code will need the physical address.
changelog:
Greg: add standalone sysfs files instead of add lines to systab
Document them as testing ABI
Greg: use group attrs and is_visible
Boris: align comments lines
Boris: add macros for _show functions
Matt: Documentation fixes.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
Documentation/ABI/testing/sysfs-firmware-efi | 24 +++++++++++++++++
arch/x86/platform/efi/efi.c | 4 +++
drivers/firmware/efi/efi.c | 39 ++++++++++++++++++++++++++++
include/linux/efi.h | 3 +++
4 files changed, 70 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi
diff --git a/Documentation/ABI/testing/sysfs-firmware-efi b/Documentation/ABI/testing/sysfs-firmware-efi
new file mode 100644
index 0000000..8c6e460
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-efi
@@ -0,0 +1,24 @@
+What: /sys/firmware/efi/fw_vendor
+Date: December 2013
+Contact: Dave Young <dyoung@redhat.com>
+Description:
+ It shows the physical address of firmware vendor field in the
+ EFI system table.
+
+Users: Kexec
+
+What: /sys/firmware/efi/runtime
+Date: December 2013
+Contact: Dave Young <dyoung@redhat.com>
+Description:
+ It shows the physical address of runtime service table entry in
+ the EFI system table.
+Users: Kexec
+
+What: /sys/firmware/efi/config_table
+Date: December 2013
+Contact: Dave Young <dyoung@redhat.com>
+Description:
+ It shows the physical address of config table entry in the EFI
+ system table.
+Users: Kexec
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 7778b5f..3e8b760 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -653,6 +653,10 @@ void __init efi_init(void)
set_bit(EFI_SYSTEM_TABLES, &x86_efi_facility);
+ efi.config_table = (unsigned long)efi.systab->tables;
+ efi.fw_vendor = (unsigned long)efi.systab->fw_vendor;
+ efi.runtime = (unsigned long)efi.systab->runtime;
+
/*
* Show what we know for posterity
*/
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index b716a66..0ecccab 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -32,6 +32,9 @@ struct efi __read_mostly efi = {
.hcdp = EFI_INVALID_TABLE_ADDR,
.uga = EFI_INVALID_TABLE_ADDR,
.uv_systab = EFI_INVALID_TABLE_ADDR,
+ .fw_vendor = EFI_INVALID_TABLE_ADDR,
+ .runtime = EFI_INVALID_TABLE_ADDR,
+ .config_table = EFI_INVALID_TABLE_ADDR,
};
EXPORT_SYMBOL(efi);
@@ -71,13 +74,49 @@ static ssize_t systab_show(struct kobject *kobj,
static struct kobj_attribute efi_attr_systab =
__ATTR(systab, 0400, systab_show, NULL);
+#define EFI_FIELD(var) efi.var
+
+#define EFI_ATTR_SHOW(name) \
+static ssize_t name##_show(struct kobject *kobj, \
+ struct kobj_attribute *attr, char *buf) \
+{ \
+ return sprintf(buf, "0x%lx\n", EFI_FIELD(name)); \
+}
+
+EFI_ATTR_SHOW(fw_vendor);
+EFI_ATTR_SHOW(runtime);
+EFI_ATTR_SHOW(config_table);
+
+static struct kobj_attribute efi_attr_fw_vendor = __ATTR_RO(fw_vendor);
+static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
+static struct kobj_attribute efi_attr_config_table = __ATTR_RO(config_table);
+
static struct attribute *efi_subsys_attrs[] = {
&efi_attr_systab.attr,
+ &efi_attr_fw_vendor.attr,
+ &efi_attr_runtime.attr,
+ &efi_attr_config_table.attr,
NULL, /* maybe more in the future? */
};
+static umode_t efi_attr_is_visible(struct kobject *kobj,
+ struct attribute *attr, int n)
+{
+ umode_t mode = attr->mode;
+
+ if (attr == &efi_attr_fw_vendor.attr)
+ return (efi.fw_vendor == EFI_INVALID_TABLE_ADDR) ? 0 : mode;
+ else if (attr == &efi_attr_runtime.attr)
+ return (efi.runtime == EFI_INVALID_TABLE_ADDR) ? 0 : mode;
+ else if (attr == &efi_attr_config_table.attr)
+ return (efi.config_table == EFI_INVALID_TABLE_ADDR) ? 0 : mode;
+
+ return mode;
+}
+
static struct attribute_group efi_subsys_attr_group = {
.attrs = efi_subsys_attrs,
+ .is_visible = efi_attr_is_visible,
};
static struct efivars generic_efivars;
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 6c0ca52..fb60b10 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -556,6 +556,9 @@ extern struct efi {
unsigned long hcdp; /* HCDP table */
unsigned long uga; /* UGA table */
unsigned long uv_systab; /* UV system table */
+ unsigned long fw_vendor; /* fw_vendor */
+ unsigned long runtime; /* runtime table */
+ unsigned long config_table; /* config tables */
efi_get_time_t *get_time;
efi_set_time_t *set_time;
efi_get_wakeup_time_t *get_wakeup_time;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 07/14] efi: export more efi table variable to sysfs
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
Export fw_vendor, runtime and config table physical addresses to
/sys/firmware/efi/fw_vendor, /sys/firmware/efi/runtime and
/sys/firmware/efi/config_table because kexec kernel will need them.
From EFI spec these 3 variables will be updated to
virtual address after entering virtual mode. But
kernel startup code will need the physical address.
changelog:
Greg: add standalone sysfs files instead of add lines to systab
Document them as testing ABI
Greg: use group attrs and is_visible
Boris: align comments lines
Boris: add macros for _show functions
Matt: Documentation fixes.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
Documentation/ABI/testing/sysfs-firmware-efi | 24 +++++++++++++++++
arch/x86/platform/efi/efi.c | 4 +++
drivers/firmware/efi/efi.c | 39 ++++++++++++++++++++++++++++
include/linux/efi.h | 3 +++
4 files changed, 70 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi
diff --git a/Documentation/ABI/testing/sysfs-firmware-efi b/Documentation/ABI/testing/sysfs-firmware-efi
new file mode 100644
index 0000000..8c6e460
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-efi
@@ -0,0 +1,24 @@
+What: /sys/firmware/efi/fw_vendor
+Date: December 2013
+Contact: Dave Young <dyoung@redhat.com>
+Description:
+ It shows the physical address of firmware vendor field in the
+ EFI system table.
+
+Users: Kexec
+
+What: /sys/firmware/efi/runtime
+Date: December 2013
+Contact: Dave Young <dyoung@redhat.com>
+Description:
+ It shows the physical address of runtime service table entry in
+ the EFI system table.
+Users: Kexec
+
+What: /sys/firmware/efi/config_table
+Date: December 2013
+Contact: Dave Young <dyoung@redhat.com>
+Description:
+ It shows the physical address of config table entry in the EFI
+ system table.
+Users: Kexec
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 7778b5f..3e8b760 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -653,6 +653,10 @@ void __init efi_init(void)
set_bit(EFI_SYSTEM_TABLES, &x86_efi_facility);
+ efi.config_table = (unsigned long)efi.systab->tables;
+ efi.fw_vendor = (unsigned long)efi.systab->fw_vendor;
+ efi.runtime = (unsigned long)efi.systab->runtime;
+
/*
* Show what we know for posterity
*/
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index b716a66..0ecccab 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -32,6 +32,9 @@ struct efi __read_mostly efi = {
.hcdp = EFI_INVALID_TABLE_ADDR,
.uga = EFI_INVALID_TABLE_ADDR,
.uv_systab = EFI_INVALID_TABLE_ADDR,
+ .fw_vendor = EFI_INVALID_TABLE_ADDR,
+ .runtime = EFI_INVALID_TABLE_ADDR,
+ .config_table = EFI_INVALID_TABLE_ADDR,
};
EXPORT_SYMBOL(efi);
@@ -71,13 +74,49 @@ static ssize_t systab_show(struct kobject *kobj,
static struct kobj_attribute efi_attr_systab =
__ATTR(systab, 0400, systab_show, NULL);
+#define EFI_FIELD(var) efi.var
+
+#define EFI_ATTR_SHOW(name) \
+static ssize_t name##_show(struct kobject *kobj, \
+ struct kobj_attribute *attr, char *buf) \
+{ \
+ return sprintf(buf, "0x%lx\n", EFI_FIELD(name)); \
+}
+
+EFI_ATTR_SHOW(fw_vendor);
+EFI_ATTR_SHOW(runtime);
+EFI_ATTR_SHOW(config_table);
+
+static struct kobj_attribute efi_attr_fw_vendor = __ATTR_RO(fw_vendor);
+static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
+static struct kobj_attribute efi_attr_config_table = __ATTR_RO(config_table);
+
static struct attribute *efi_subsys_attrs[] = {
&efi_attr_systab.attr,
+ &efi_attr_fw_vendor.attr,
+ &efi_attr_runtime.attr,
+ &efi_attr_config_table.attr,
NULL, /* maybe more in the future? */
};
+static umode_t efi_attr_is_visible(struct kobject *kobj,
+ struct attribute *attr, int n)
+{
+ umode_t mode = attr->mode;
+
+ if (attr == &efi_attr_fw_vendor.attr)
+ return (efi.fw_vendor == EFI_INVALID_TABLE_ADDR) ? 0 : mode;
+ else if (attr == &efi_attr_runtime.attr)
+ return (efi.runtime == EFI_INVALID_TABLE_ADDR) ? 0 : mode;
+ else if (attr == &efi_attr_config_table.attr)
+ return (efi.config_table == EFI_INVALID_TABLE_ADDR) ? 0 : mode;
+
+ return mode;
+}
+
static struct attribute_group efi_subsys_attr_group = {
.attrs = efi_subsys_attrs,
+ .is_visible = efi_attr_is_visible,
};
static struct efivars generic_efivars;
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 6c0ca52..fb60b10 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -556,6 +556,9 @@ extern struct efi {
unsigned long hcdp; /* HCDP table */
unsigned long uga; /* UGA table */
unsigned long uv_systab; /* UV system table */
+ unsigned long fw_vendor; /* fw_vendor */
+ unsigned long runtime; /* runtime table */
+ unsigned long config_table; /* config tables */
efi_get_time_t *get_time;
efi_set_time_t *set_time;
efi_get_wakeup_time_t *get_wakeup_time;
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 07/14] efi: export more efi table variable to sysfs
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
Export fw_vendor, runtime and config table physical addresses to
/sys/firmware/efi/fw_vendor, /sys/firmware/efi/runtime and
/sys/firmware/efi/config_table because kexec kernel will need them.
>From EFI spec these 3 variables will be updated to
virtual address after entering virtual mode. But
kernel startup code will need the physical address.
changelog:
Greg: add standalone sysfs files instead of add lines to systab
Document them as testing ABI
Greg: use group attrs and is_visible
Boris: align comments lines
Boris: add macros for _show functions
Matt: Documentation fixes.
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
Documentation/ABI/testing/sysfs-firmware-efi | 24 +++++++++++++++++
arch/x86/platform/efi/efi.c | 4 +++
drivers/firmware/efi/efi.c | 39 ++++++++++++++++++++++++++++
include/linux/efi.h | 3 +++
4 files changed, 70 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi
diff --git a/Documentation/ABI/testing/sysfs-firmware-efi b/Documentation/ABI/testing/sysfs-firmware-efi
new file mode 100644
index 0000000..8c6e460
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-efi
@@ -0,0 +1,24 @@
+What: /sys/firmware/efi/fw_vendor
+Date: December 2013
+Contact: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
+Description:
+ It shows the physical address of firmware vendor field in the
+ EFI system table.
+
+Users: Kexec
+
+What: /sys/firmware/efi/runtime
+Date: December 2013
+Contact: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
+Description:
+ It shows the physical address of runtime service table entry in
+ the EFI system table.
+Users: Kexec
+
+What: /sys/firmware/efi/config_table
+Date: December 2013
+Contact: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
+Description:
+ It shows the physical address of config table entry in the EFI
+ system table.
+Users: Kexec
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 7778b5f..3e8b760 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -653,6 +653,10 @@ void __init efi_init(void)
set_bit(EFI_SYSTEM_TABLES, &x86_efi_facility);
+ efi.config_table = (unsigned long)efi.systab->tables;
+ efi.fw_vendor = (unsigned long)efi.systab->fw_vendor;
+ efi.runtime = (unsigned long)efi.systab->runtime;
+
/*
* Show what we know for posterity
*/
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index b716a66..0ecccab 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -32,6 +32,9 @@ struct efi __read_mostly efi = {
.hcdp = EFI_INVALID_TABLE_ADDR,
.uga = EFI_INVALID_TABLE_ADDR,
.uv_systab = EFI_INVALID_TABLE_ADDR,
+ .fw_vendor = EFI_INVALID_TABLE_ADDR,
+ .runtime = EFI_INVALID_TABLE_ADDR,
+ .config_table = EFI_INVALID_TABLE_ADDR,
};
EXPORT_SYMBOL(efi);
@@ -71,13 +74,49 @@ static ssize_t systab_show(struct kobject *kobj,
static struct kobj_attribute efi_attr_systab =
__ATTR(systab, 0400, systab_show, NULL);
+#define EFI_FIELD(var) efi.var
+
+#define EFI_ATTR_SHOW(name) \
+static ssize_t name##_show(struct kobject *kobj, \
+ struct kobj_attribute *attr, char *buf) \
+{ \
+ return sprintf(buf, "0x%lx\n", EFI_FIELD(name)); \
+}
+
+EFI_ATTR_SHOW(fw_vendor);
+EFI_ATTR_SHOW(runtime);
+EFI_ATTR_SHOW(config_table);
+
+static struct kobj_attribute efi_attr_fw_vendor = __ATTR_RO(fw_vendor);
+static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
+static struct kobj_attribute efi_attr_config_table = __ATTR_RO(config_table);
+
static struct attribute *efi_subsys_attrs[] = {
&efi_attr_systab.attr,
+ &efi_attr_fw_vendor.attr,
+ &efi_attr_runtime.attr,
+ &efi_attr_config_table.attr,
NULL, /* maybe more in the future? */
};
+static umode_t efi_attr_is_visible(struct kobject *kobj,
+ struct attribute *attr, int n)
+{
+ umode_t mode = attr->mode;
+
+ if (attr == &efi_attr_fw_vendor.attr)
+ return (efi.fw_vendor == EFI_INVALID_TABLE_ADDR) ? 0 : mode;
+ else if (attr == &efi_attr_runtime.attr)
+ return (efi.runtime == EFI_INVALID_TABLE_ADDR) ? 0 : mode;
+ else if (attr == &efi_attr_config_table.attr)
+ return (efi.config_table == EFI_INVALID_TABLE_ADDR) ? 0 : mode;
+
+ return mode;
+}
+
static struct attribute_group efi_subsys_attr_group = {
.attrs = efi_subsys_attrs,
+ .is_visible = efi_attr_is_visible,
};
static struct efivars generic_efivars;
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 6c0ca52..fb60b10 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -556,6 +556,9 @@ extern struct efi {
unsigned long hcdp; /* HCDP table */
unsigned long uga; /* UGA table */
unsigned long uv_systab; /* UV system table */
+ unsigned long fw_vendor; /* fw_vendor */
+ unsigned long runtime; /* runtime table */
+ unsigned long config_table; /* config tables */
efi_get_time_t *get_time;
efi_set_time_t *set_time;
efi_get_wakeup_time_t *get_wakeup_time;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH v5 07/14] efi: export more efi table variable to sysfs
@ 2013-12-11 18:32 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 18:32 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On Mon, Dec 09, 2013 at 05:42:20PM +0800, Dave Young wrote:
> Export fw_vendor, runtime and config table physical addresses to
> /sys/firmware/efi/fw_vendor, /sys/firmware/efi/runtime and
> /sys/firmware/efi/config_table because kexec kernel will need them.
you might wanna shorten:
... sys/firmware/efi/{fw_vendor,runtime,config_table} ...
>
> From EFI spec these 3 variables will be updated to
> virtual address after entering virtual mode. But
> kernel startup code will need the physical address.
>
> changelog:
> Greg: add standalone sysfs files instead of add lines to systab
> Document them as testing ABI
> Greg: use group attrs and is_visible
> Boris: align comments lines
> Boris: add macros for _show functions
> Matt: Documentation fixes.
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> Documentation/ABI/testing/sysfs-firmware-efi | 24 +++++++++++++++++
> arch/x86/platform/efi/efi.c | 4 +++
> drivers/firmware/efi/efi.c | 39 ++++++++++++++++++++++++++++
> include/linux/efi.h | 3 +++
> 4 files changed, 70 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-efi b/Documentation/ABI/testing/sysfs-firmware-efi
> new file mode 100644
> index 0000000..8c6e460
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-firmware-efi
> @@ -0,0 +1,24 @@
> +What: /sys/firmware/efi/fw_vendor
> +Date: December 2013
> +Contact: Dave Young <dyoung@redhat.com>
> +Description:
> + It shows the physical address of firmware vendor field in the
Why doesn't this start at the same line as "Description:"?
> + EFI system table.
> +
Superfluous newline.
> +Users: Kexec
> +
> +What: /sys/firmware/efi/runtime
> +Date: December 2013
> +Contact: Dave Young <dyoung@redhat.com>
> +Description:
> + It shows the physical address of runtime service table entry in
> + the EFI system table.
> +Users: Kexec
> +
> +What: /sys/firmware/efi/config_table
> +Date: December 2013
> +Contact: Dave Young <dyoung@redhat.com>
> +Description:
> + It shows the physical address of config table entry in the EFI
> + system table.
> +Users: Kexec
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 7778b5f..3e8b760 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -653,6 +653,10 @@ void __init efi_init(void)
>
> set_bit(EFI_SYSTEM_TABLES, &x86_efi_facility);
>
> + efi.config_table = (unsigned long)efi.systab->tables;
> + efi.fw_vendor = (unsigned long)efi.systab->fw_vendor;
> + efi.runtime = (unsigned long)efi.systab->runtime;
> +
> /*
> * Show what we know for posterity
> */
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index b716a66..0ecccab 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -32,6 +32,9 @@ struct efi __read_mostly efi = {
> .hcdp = EFI_INVALID_TABLE_ADDR,
> .uga = EFI_INVALID_TABLE_ADDR,
> .uv_systab = EFI_INVALID_TABLE_ADDR,
> + .fw_vendor = EFI_INVALID_TABLE_ADDR,
> + .runtime = EFI_INVALID_TABLE_ADDR,
> + .config_table = EFI_INVALID_TABLE_ADDR,
> };
> EXPORT_SYMBOL(efi);
>
> @@ -71,13 +74,49 @@ static ssize_t systab_show(struct kobject *kobj,
> static struct kobj_attribute efi_attr_systab =
> __ATTR(systab, 0400, systab_show, NULL);
>
> +#define EFI_FIELD(var) efi.var
> +
> +#define EFI_ATTR_SHOW(name) \
> +static ssize_t name##_show(struct kobject *kobj, \
> + struct kobj_attribute *attr, char *buf) \
> +{ \
> + return sprintf(buf, "0x%lx\n", EFI_FIELD(name)); \
> +}
> +
> +EFI_ATTR_SHOW(fw_vendor);
> +EFI_ATTR_SHOW(runtime);
> +EFI_ATTR_SHOW(config_table);
> +
> +static struct kobj_attribute efi_attr_fw_vendor = __ATTR_RO(fw_vendor);
> +static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
> +static struct kobj_attribute efi_attr_config_table = __ATTR_RO(config_table);
> +
> static struct attribute *efi_subsys_attrs[] = {
> &efi_attr_systab.attr,
> + &efi_attr_fw_vendor.attr,
> + &efi_attr_runtime.attr,
> + &efi_attr_config_table.attr,
> NULL, /* maybe more in the future? */
^^^^^
Now that there's more, you can drop that wise guy comment :)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 07/14] efi: export more efi table variable to sysfs
@ 2013-12-11 18:32 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 18:32 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On Mon, Dec 09, 2013 at 05:42:20PM +0800, Dave Young wrote:
> Export fw_vendor, runtime and config table physical addresses to
> /sys/firmware/efi/fw_vendor, /sys/firmware/efi/runtime and
> /sys/firmware/efi/config_table because kexec kernel will need them.
you might wanna shorten:
... sys/firmware/efi/{fw_vendor,runtime,config_table} ...
>
> From EFI spec these 3 variables will be updated to
> virtual address after entering virtual mode. But
> kernel startup code will need the physical address.
>
> changelog:
> Greg: add standalone sysfs files instead of add lines to systab
> Document them as testing ABI
> Greg: use group attrs and is_visible
> Boris: align comments lines
> Boris: add macros for _show functions
> Matt: Documentation fixes.
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> Documentation/ABI/testing/sysfs-firmware-efi | 24 +++++++++++++++++
> arch/x86/platform/efi/efi.c | 4 +++
> drivers/firmware/efi/efi.c | 39 ++++++++++++++++++++++++++++
> include/linux/efi.h | 3 +++
> 4 files changed, 70 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-efi b/Documentation/ABI/testing/sysfs-firmware-efi
> new file mode 100644
> index 0000000..8c6e460
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-firmware-efi
> @@ -0,0 +1,24 @@
> +What: /sys/firmware/efi/fw_vendor
> +Date: December 2013
> +Contact: Dave Young <dyoung@redhat.com>
> +Description:
> + It shows the physical address of firmware vendor field in the
Why doesn't this start at the same line as "Description:"?
> + EFI system table.
> +
Superfluous newline.
> +Users: Kexec
> +
> +What: /sys/firmware/efi/runtime
> +Date: December 2013
> +Contact: Dave Young <dyoung@redhat.com>
> +Description:
> + It shows the physical address of runtime service table entry in
> + the EFI system table.
> +Users: Kexec
> +
> +What: /sys/firmware/efi/config_table
> +Date: December 2013
> +Contact: Dave Young <dyoung@redhat.com>
> +Description:
> + It shows the physical address of config table entry in the EFI
> + system table.
> +Users: Kexec
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 7778b5f..3e8b760 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -653,6 +653,10 @@ void __init efi_init(void)
>
> set_bit(EFI_SYSTEM_TABLES, &x86_efi_facility);
>
> + efi.config_table = (unsigned long)efi.systab->tables;
> + efi.fw_vendor = (unsigned long)efi.systab->fw_vendor;
> + efi.runtime = (unsigned long)efi.systab->runtime;
> +
> /*
> * Show what we know for posterity
> */
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index b716a66..0ecccab 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -32,6 +32,9 @@ struct efi __read_mostly efi = {
> .hcdp = EFI_INVALID_TABLE_ADDR,
> .uga = EFI_INVALID_TABLE_ADDR,
> .uv_systab = EFI_INVALID_TABLE_ADDR,
> + .fw_vendor = EFI_INVALID_TABLE_ADDR,
> + .runtime = EFI_INVALID_TABLE_ADDR,
> + .config_table = EFI_INVALID_TABLE_ADDR,
> };
> EXPORT_SYMBOL(efi);
>
> @@ -71,13 +74,49 @@ static ssize_t systab_show(struct kobject *kobj,
> static struct kobj_attribute efi_attr_systab =
> __ATTR(systab, 0400, systab_show, NULL);
>
> +#define EFI_FIELD(var) efi.var
> +
> +#define EFI_ATTR_SHOW(name) \
> +static ssize_t name##_show(struct kobject *kobj, \
> + struct kobj_attribute *attr, char *buf) \
> +{ \
> + return sprintf(buf, "0x%lx\n", EFI_FIELD(name)); \
> +}
> +
> +EFI_ATTR_SHOW(fw_vendor);
> +EFI_ATTR_SHOW(runtime);
> +EFI_ATTR_SHOW(config_table);
> +
> +static struct kobj_attribute efi_attr_fw_vendor = __ATTR_RO(fw_vendor);
> +static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
> +static struct kobj_attribute efi_attr_config_table = __ATTR_RO(config_table);
> +
> static struct attribute *efi_subsys_attrs[] = {
> &efi_attr_systab.attr,
> + &efi_attr_fw_vendor.attr,
> + &efi_attr_runtime.attr,
> + &efi_attr_config_table.attr,
> NULL, /* maybe more in the future? */
^^^^^
Now that there's more, you can drop that wise guy comment :)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 07/14] efi: export more efi table variable to sysfs
@ 2013-12-11 18:32 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 18:32 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On Mon, Dec 09, 2013 at 05:42:20PM +0800, Dave Young wrote:
> Export fw_vendor, runtime and config table physical addresses to
> /sys/firmware/efi/fw_vendor, /sys/firmware/efi/runtime and
> /sys/firmware/efi/config_table because kexec kernel will need them.
you might wanna shorten:
... sys/firmware/efi/{fw_vendor,runtime,config_table} ...
>
> From EFI spec these 3 variables will be updated to
> virtual address after entering virtual mode. But
> kernel startup code will need the physical address.
>
> changelog:
> Greg: add standalone sysfs files instead of add lines to systab
> Document them as testing ABI
> Greg: use group attrs and is_visible
> Boris: align comments lines
> Boris: add macros for _show functions
> Matt: Documentation fixes.
>
> Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> Documentation/ABI/testing/sysfs-firmware-efi | 24 +++++++++++++++++
> arch/x86/platform/efi/efi.c | 4 +++
> drivers/firmware/efi/efi.c | 39 ++++++++++++++++++++++++++++
> include/linux/efi.h | 3 +++
> 4 files changed, 70 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-efi b/Documentation/ABI/testing/sysfs-firmware-efi
> new file mode 100644
> index 0000000..8c6e460
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-firmware-efi
> @@ -0,0 +1,24 @@
> +What: /sys/firmware/efi/fw_vendor
> +Date: December 2013
> +Contact: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> +Description:
> + It shows the physical address of firmware vendor field in the
Why doesn't this start at the same line as "Description:"?
> + EFI system table.
> +
Superfluous newline.
> +Users: Kexec
> +
> +What: /sys/firmware/efi/runtime
> +Date: December 2013
> +Contact: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> +Description:
> + It shows the physical address of runtime service table entry in
> + the EFI system table.
> +Users: Kexec
> +
> +What: /sys/firmware/efi/config_table
> +Date: December 2013
> +Contact: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> +Description:
> + It shows the physical address of config table entry in the EFI
> + system table.
> +Users: Kexec
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 7778b5f..3e8b760 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -653,6 +653,10 @@ void __init efi_init(void)
>
> set_bit(EFI_SYSTEM_TABLES, &x86_efi_facility);
>
> + efi.config_table = (unsigned long)efi.systab->tables;
> + efi.fw_vendor = (unsigned long)efi.systab->fw_vendor;
> + efi.runtime = (unsigned long)efi.systab->runtime;
> +
> /*
> * Show what we know for posterity
> */
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index b716a66..0ecccab 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -32,6 +32,9 @@ struct efi __read_mostly efi = {
> .hcdp = EFI_INVALID_TABLE_ADDR,
> .uga = EFI_INVALID_TABLE_ADDR,
> .uv_systab = EFI_INVALID_TABLE_ADDR,
> + .fw_vendor = EFI_INVALID_TABLE_ADDR,
> + .runtime = EFI_INVALID_TABLE_ADDR,
> + .config_table = EFI_INVALID_TABLE_ADDR,
> };
> EXPORT_SYMBOL(efi);
>
> @@ -71,13 +74,49 @@ static ssize_t systab_show(struct kobject *kobj,
> static struct kobj_attribute efi_attr_systab =
> __ATTR(systab, 0400, systab_show, NULL);
>
> +#define EFI_FIELD(var) efi.var
> +
> +#define EFI_ATTR_SHOW(name) \
> +static ssize_t name##_show(struct kobject *kobj, \
> + struct kobj_attribute *attr, char *buf) \
> +{ \
> + return sprintf(buf, "0x%lx\n", EFI_FIELD(name)); \
> +}
> +
> +EFI_ATTR_SHOW(fw_vendor);
> +EFI_ATTR_SHOW(runtime);
> +EFI_ATTR_SHOW(config_table);
> +
> +static struct kobj_attribute efi_attr_fw_vendor = __ATTR_RO(fw_vendor);
> +static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
> +static struct kobj_attribute efi_attr_config_table = __ATTR_RO(config_table);
> +
> static struct attribute *efi_subsys_attrs[] = {
> &efi_attr_systab.attr,
> + &efi_attr_fw_vendor.attr,
> + &efi_attr_runtime.attr,
> + &efi_attr_config_table.attr,
> NULL, /* maybe more in the future? */
^^^^^
Now that there's more, you can drop that wise guy comment :)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 07/14] efi: export more efi table variable to sysfs
@ 2013-12-12 2:15 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:15 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On 12/11/13 at 07:32pm, Borislav Petkov wrote:
> On Mon, Dec 09, 2013 at 05:42:20PM +0800, Dave Young wrote:
> > Export fw_vendor, runtime and config table physical addresses to
> > /sys/firmware/efi/fw_vendor, /sys/firmware/efi/runtime and
> > /sys/firmware/efi/config_table because kexec kernel will need them.
>
> you might wanna shorten:
>
> ... sys/firmware/efi/{fw_vendor,runtime,config_table} ...
Ok, will do.
>
> >
> > From EFI spec these 3 variables will be updated to
> > virtual address after entering virtual mode. But
> > kernel startup code will need the physical address.
> >
> > changelog:
> > Greg: add standalone sysfs files instead of add lines to systab
> > Document them as testing ABI
> > Greg: use group attrs and is_visible
> > Boris: align comments lines
> > Boris: add macros for _show functions
> > Matt: Documentation fixes.
> >
> > Signed-off-by: Dave Young <dyoung@redhat.com>
> > ---
> > Documentation/ABI/testing/sysfs-firmware-efi | 24 +++++++++++++++++
> > arch/x86/platform/efi/efi.c | 4 +++
> > drivers/firmware/efi/efi.c | 39 ++++++++++++++++++++++++++++
> > include/linux/efi.h | 3 +++
> > 4 files changed, 70 insertions(+)
> > create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi
> >
> > diff --git a/Documentation/ABI/testing/sysfs-firmware-efi b/Documentation/ABI/testing/sysfs-firmware-efi
> > new file mode 100644
> > index 0000000..8c6e460
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-firmware-efi
> > @@ -0,0 +1,24 @@
> > +What: /sys/firmware/efi/fw_vendor
> > +Date: December 2013
> > +Contact: Dave Young <dyoung@redhat.com>
> > +Description:
> > + It shows the physical address of firmware vendor field in the
>
> Why doesn't this start at the same line as "Description:"?
It can, just in 1st version I copied the format from some template, I have
found it's better so updated the Users line but missed the Description.
Will do in next version.
>
> > + EFI system table.
> > +
>
> Superfluous newline.
Will remove it.
[snip]
> > +
> > static struct attribute *efi_subsys_attrs[] = {
> > &efi_attr_systab.attr,
> > + &efi_attr_fw_vendor.attr,
> > + &efi_attr_runtime.attr,
> > + &efi_attr_config_table.attr,
> > NULL, /* maybe more in the future? */
> ^^^^^
>
> Now that there's more, you can drop that wise guy comment :)
Ok.
--
Thanks for review
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 07/14] efi: export more efi table variable to sysfs
@ 2013-12-12 2:15 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:15 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On 12/11/13 at 07:32pm, Borislav Petkov wrote:
> On Mon, Dec 09, 2013 at 05:42:20PM +0800, Dave Young wrote:
> > Export fw_vendor, runtime and config table physical addresses to
> > /sys/firmware/efi/fw_vendor, /sys/firmware/efi/runtime and
> > /sys/firmware/efi/config_table because kexec kernel will need them.
>
> you might wanna shorten:
>
> ... sys/firmware/efi/{fw_vendor,runtime,config_table} ...
Ok, will do.
>
> >
> > From EFI spec these 3 variables will be updated to
> > virtual address after entering virtual mode. But
> > kernel startup code will need the physical address.
> >
> > changelog:
> > Greg: add standalone sysfs files instead of add lines to systab
> > Document them as testing ABI
> > Greg: use group attrs and is_visible
> > Boris: align comments lines
> > Boris: add macros for _show functions
> > Matt: Documentation fixes.
> >
> > Signed-off-by: Dave Young <dyoung@redhat.com>
> > ---
> > Documentation/ABI/testing/sysfs-firmware-efi | 24 +++++++++++++++++
> > arch/x86/platform/efi/efi.c | 4 +++
> > drivers/firmware/efi/efi.c | 39 ++++++++++++++++++++++++++++
> > include/linux/efi.h | 3 +++
> > 4 files changed, 70 insertions(+)
> > create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi
> >
> > diff --git a/Documentation/ABI/testing/sysfs-firmware-efi b/Documentation/ABI/testing/sysfs-firmware-efi
> > new file mode 100644
> > index 0000000..8c6e460
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-firmware-efi
> > @@ -0,0 +1,24 @@
> > +What: /sys/firmware/efi/fw_vendor
> > +Date: December 2013
> > +Contact: Dave Young <dyoung@redhat.com>
> > +Description:
> > + It shows the physical address of firmware vendor field in the
>
> Why doesn't this start at the same line as "Description:"?
It can, just in 1st version I copied the format from some template, I have
found it's better so updated the Users line but missed the Description.
Will do in next version.
>
> > + EFI system table.
> > +
>
> Superfluous newline.
Will remove it.
[snip]
> > +
> > static struct attribute *efi_subsys_attrs[] = {
> > &efi_attr_systab.attr,
> > + &efi_attr_fw_vendor.attr,
> > + &efi_attr_runtime.attr,
> > + &efi_attr_config_table.attr,
> > NULL, /* maybe more in the future? */
> ^^^^^
>
> Now that there's more, you can drop that wise guy comment :)
Ok.
--
Thanks for review
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 07/14] efi: export more efi table variable to sysfs
@ 2013-12-12 2:15 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:15 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On 12/11/13 at 07:32pm, Borislav Petkov wrote:
> On Mon, Dec 09, 2013 at 05:42:20PM +0800, Dave Young wrote:
> > Export fw_vendor, runtime and config table physical addresses to
> > /sys/firmware/efi/fw_vendor, /sys/firmware/efi/runtime and
> > /sys/firmware/efi/config_table because kexec kernel will need them.
>
> you might wanna shorten:
>
> ... sys/firmware/efi/{fw_vendor,runtime,config_table} ...
Ok, will do.
>
> >
> > From EFI spec these 3 variables will be updated to
> > virtual address after entering virtual mode. But
> > kernel startup code will need the physical address.
> >
> > changelog:
> > Greg: add standalone sysfs files instead of add lines to systab
> > Document them as testing ABI
> > Greg: use group attrs and is_visible
> > Boris: align comments lines
> > Boris: add macros for _show functions
> > Matt: Documentation fixes.
> >
> > Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > ---
> > Documentation/ABI/testing/sysfs-firmware-efi | 24 +++++++++++++++++
> > arch/x86/platform/efi/efi.c | 4 +++
> > drivers/firmware/efi/efi.c | 39 ++++++++++++++++++++++++++++
> > include/linux/efi.h | 3 +++
> > 4 files changed, 70 insertions(+)
> > create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi
> >
> > diff --git a/Documentation/ABI/testing/sysfs-firmware-efi b/Documentation/ABI/testing/sysfs-firmware-efi
> > new file mode 100644
> > index 0000000..8c6e460
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-firmware-efi
> > @@ -0,0 +1,24 @@
> > +What: /sys/firmware/efi/fw_vendor
> > +Date: December 2013
> > +Contact: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > +Description:
> > + It shows the physical address of firmware vendor field in the
>
> Why doesn't this start at the same line as "Description:"?
It can, just in 1st version I copied the format from some template, I have
found it's better so updated the Users line but missed the Description.
Will do in next version.
>
> > + EFI system table.
> > +
>
> Superfluous newline.
Will remove it.
[snip]
> > +
> > static struct attribute *efi_subsys_attrs[] = {
> > &efi_attr_systab.attr,
> > + &efi_attr_fw_vendor.attr,
> > + &efi_attr_runtime.attr,
> > + &efi_attr_config_table.attr,
> > NULL, /* maybe more in the future? */
> ^^^^^
>
> Now that there's more, you can drop that wise guy comment :)
Ok.
--
Thanks for review
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.
Introducing a new directory /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap. Containing below attribute
in each file of that directory:
attribute num_pages phys_addr type virt_addr
Matt: s/efi-runtime-map.c/runtime-map.c
change dir name to runtime-map
update to use desc_size in efi_runtime_map
cleaup the code, add function efi_save_runtime_map
improve err handling
Matt: changelog fix;
Documentation fixes.
only export runtime-map sysfs file in case CONFIG_KEXEC
Add macros for sysfs _show functions
move functions to front of .c, remove forward declarations.
Boris: Documentation grammer/spelling fix
better error handling for krealloc
other code improvements.
move efi_runtime_map_init to subsys_initcall.
set efi_kobj = NULL in case efisubsys_init fails. And then efi_runtime_map_init
will bail out.
Kconfig EFI_RUNTIME_MAP depends on X86 && KEXEC && EFI
Signed-off-by: Dave Young <dyoung@redhat.com>
---
.../ABI/testing/sysfs-firmware-efi-runtime-map | 36 +++++
arch/x86/platform/efi/efi.c | 28 ++++
drivers/firmware/efi/Kconfig | 11 ++
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/efi.c | 4 +-
drivers/firmware/efi/runtime-map.c | 176 +++++++++++++++++++++
include/linux/efi.h | 6 +
7 files changed, 261 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
create mode 100644 drivers/firmware/efi/runtime-map.c
diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
new file mode 100644
index 0000000..2ab7dd2
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
@@ -0,0 +1,36 @@
+What: /sys/firmware/efi/runtime-map/
+Date: December 2013
+Contact: Dave Young <dyoung@redhat.com>
+Description:
+ Switching efi runtime services to virtual mode requires
+ that all efi memory ranges which have the runtime attribute
+ bit set to be mapped to virtual addresses.
+
+ The efi runtime services can only be switched to virtual
+ mode once without rebooting. The kexec kernel must maintain
+ the same physical to virtual address mappings as the first
+ kernel. The mappings are exported to sysfs so userspace tools
+ can reassemble them and pass them into the kexec kernel.
+
+ /sys/firmware/efi/runtime-map/ is the directory the kernel
+ exports that information in.
+
+ subdirectories are named with the number of the memory range:
+
+ /sys/firmware/efi/runtime-map/0
+ /sys/firmware/efi/runtime-map/1
+ /sys/firmware/efi/runtime-map/2
+ /sys/firmware/efi/runtime-map/3
+ ...
+
+ Each subdirectory contains five files:
+
+ attribute : The attributes of the memory range.
+ num_pages : The size of the memory range in pages.
+ phys_addr : The physical address of the memory range.
+ type : The type of the memory range.
+ virt_addr : The virtual address of the memory range.
+
+ Above values are all hexadecimal numbers with the '0x' prefix.
+
+Users: Kexec
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 3e8b760..8289e0c 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
{NULL_GUID, NULL, NULL},
};
+void *efi_runtime_map;
+int nr_efi_runtime_map;
+
/*
* Returns 1 if 'facility' is enabled, 0 otherwise.
*/
@@ -810,6 +813,19 @@ static void __init efi_merge_regions(void)
}
}
+static int __init save_runtime_map(efi_memory_desc_t *md, int idx)
+{
+ void *p;
+ p = krealloc(efi_runtime_map, (idx + 1) * memmap.desc_size, GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ efi_runtime_map = p;
+ memcpy(efi_runtime_map + idx * memmap.desc_size, md, memmap.desc_size);
+
+ return 0;
+}
+
/*
* Map efi memory ranges for runtime serivce and update new_memmap with virtual
* addresses.
@@ -820,6 +836,7 @@ static void * __init efi_map_regions(int *count)
void *p, *tmp, *new_memmap = NULL;
unsigned long size;
u64 end, systab;
+ int err = 0;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
@@ -848,10 +865,21 @@ static void * __init efi_map_regions(int *count)
new_memmap = tmp;
memcpy(new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
+ if (md->type != EFI_BOOT_SERVICES_CODE &&
+ md->type != EFI_BOOT_SERVICES_DATA) {
+ err = save_runtime_map(md, nr_efi_runtime_map);
+ if (err)
+ goto out_save_runtime;
+ nr_efi_runtime_map++;
+ }
(*count)++;
}
return new_memmap;
+out_save_runtime:
+ kfree(efi_runtime_map);
+ nr_efi_runtime_map = 0;
+ efi_runtime_map = NULL;
out_krealloc:
kfree(new_memmap);
return NULL;
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 3150aa4..3d8d6f6 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -39,4 +39,15 @@ config EFI_VARS_PSTORE_DEFAULT_DISABLE
config UEFI_CPER
def_bool n
+config EFI_RUNTIME_MAP
+ bool "Export efi runtime maps to sysfs" if EXPERT
+ depends on X86 && EFI && KEXEC
+ default y
+ help
+ Export efi runtime memory maps to /sys/firmware/efi/runtime-map.
+ That memory map is used for example by kexec to set up efi virtual
+ mapping the 2nd kernel, but can also be used for debugging purposes.
+
+ See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map.
+
endmenu
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 9ba156d..a58e0f1 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -5,3 +5,4 @@ obj-y += efi.o vars.o
obj-$(CONFIG_EFI_VARS) += efivars.o
obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o
obj-$(CONFIG_UEFI_CPER) += cper.o
+obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 0ecccab..0a288e3 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -38,7 +38,8 @@ struct efi __read_mostly efi = {
};
EXPORT_SYMBOL(efi);
-static struct kobject *efi_kobj;
+struct kobject *efi_kobj;
+EXPORT_SYMBOL_GPL(efi_kobj);
static struct kobject *efivars_kobj;
/*
@@ -183,6 +184,7 @@ err_unregister:
generic_ops_unregister();
err_put:
kobject_put(efi_kobj);
+ efi_kobj = NULL;
return error;
}
diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
new file mode 100644
index 0000000..e5e9984
--- /dev/null
+++ b/drivers/firmware/efi/runtime-map.c
@@ -0,0 +1,176 @@
+/*
+ * linux/drivers/efi/runtime-map.c
+ * Copyright (C) 2013 Red Hat, Inc., Dave Young <dyoung@redhat.com>
+ *
+ * This file is released under the GPLv2.
+ */
+
+#include <linux/string.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/efi.h>
+#include <linux/slab.h>
+
+#include <asm/setup.h>
+
+struct efi_runtime_map_entry {
+ efi_memory_desc_t md;
+ struct kobject kobj; /* kobject for each entry */
+};
+
+static struct efi_runtime_map_entry **map_entries;
+
+struct map_attribute {
+ struct attribute attr;
+ ssize_t (*show)(struct efi_runtime_map_entry *entry, char *buf);
+};
+
+static inline struct map_attribute *to_map_attr(struct attribute *attr)
+{
+ return container_of(attr, struct map_attribute, attr);
+}
+
+static ssize_t type_show(struct efi_runtime_map_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%x\n", entry->md.type);
+}
+
+#define EFI_RUNTIME_FIELD(var) entry->md.var
+
+#define EFI_RUNTIME_U64_ATTR_SHOW(name) \
+static ssize_t name##_show(struct efi_runtime_map_entry *entry, char *buf) \
+{ \
+ return snprintf(buf, PAGE_SIZE, "0x%llx\n", EFI_RUNTIME_FIELD(name)); \
+}
+
+EFI_RUNTIME_U64_ATTR_SHOW(phys_addr);
+EFI_RUNTIME_U64_ATTR_SHOW(virt_addr);
+EFI_RUNTIME_U64_ATTR_SHOW(num_pages);
+EFI_RUNTIME_U64_ATTR_SHOW(attribute);
+
+static inline struct efi_runtime_map_entry *to_map_entry(struct kobject *kobj)
+{
+ return container_of(kobj, struct efi_runtime_map_entry, kobj);
+}
+
+static ssize_t map_attr_show(struct kobject *kobj, struct attribute *attr,
+ char *buf)
+{
+ struct efi_runtime_map_entry *entry = to_map_entry(kobj);
+ struct map_attribute *map_attr = to_map_attr(attr);
+
+ return map_attr->show(entry, buf);
+}
+
+static struct map_attribute map_type_attr = __ATTR_RO(type);
+static struct map_attribute map_phys_addr_attr = __ATTR_RO(phys_addr);
+static struct map_attribute map_virt_addr_attr = __ATTR_RO(virt_addr);
+static struct map_attribute map_num_pages_attr = __ATTR_RO(num_pages);
+static struct map_attribute map_attribute_attr = __ATTR_RO(attribute);
+
+/*
+ * These are default attributes that are added for every memmap entry.
+ */
+static struct attribute *def_attrs[] = {
+ &map_type_attr.attr,
+ &map_phys_addr_attr.attr,
+ &map_virt_addr_attr.attr,
+ &map_num_pages_attr.attr,
+ &map_attribute_attr.attr,
+ NULL
+};
+
+static const struct sysfs_ops map_attr_ops = {
+ .show = map_attr_show,
+};
+
+static void map_release(struct kobject *kobj)
+{
+ struct efi_runtime_map_entry *entry;
+
+ entry = to_map_entry(kobj);
+ kfree(entry);
+}
+
+static struct kobj_type __refdata map_ktype = {
+ .sysfs_ops = &map_attr_ops,
+ .default_attrs = def_attrs,
+ .release = map_release,
+};
+
+static struct kset *map_kset;
+
+static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
+{
+ int ret;
+ struct efi_runtime_map_entry *entry;
+ struct efi_info *e = &boot_params.efi_info;
+
+ if (!map_kset) {
+ map_kset = kset_create_and_add("runtime-map", NULL,
+ efi_kobj);
+ if (!map_kset)
+ return ERR_PTR(-ENOMEM);
+ }
+
+ entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry) {
+ kset_unregister(map_kset);
+ return entry;
+ }
+
+ memcpy(&entry->md, efi_runtime_map + nr * e->efi_memdesc_size,
+ sizeof(efi_memory_desc_t));
+
+ kobject_init(&entry->kobj, &map_ktype);
+ entry->kobj.kset = map_kset;
+ ret = kobject_add(&entry->kobj, NULL, "%d", nr);
+ if (ret) {
+ kobject_put(&entry->kobj);
+ kset_unregister(map_kset);
+ return ERR_PTR(ret);
+ }
+
+ return entry;
+}
+
+static int __init efi_runtime_map_init(void)
+{
+ int i, j, ret = 0;
+ struct efi_runtime_map_entry *entry;
+
+ if (!efi_kobj)
+ return 0;
+
+ if (!efi_runtime_map)
+ return 0;
+
+ map_entries = kzalloc(nr_efi_runtime_map * sizeof(entry), GFP_KERNEL);
+ if (!map_entries) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ for (i = 0; i < nr_efi_runtime_map; i++) {
+ entry = add_sysfs_runtime_map_entry(i);
+ if (IS_ERR(entry)) {
+ ret = PTR_ERR(entry);
+ goto out_add_entry;
+ }
+ *(map_entries + i) = entry;
+ }
+
+ return 0;
+out_add_entry:
+ for (j = i - 1; j > 0; j--) {
+ entry = *(map_entries + j);
+ kobject_put(&entry->kobj);
+ }
+ if (map_kset)
+ kset_unregister(map_kset);
+out:
+ return ret;
+}
+
+subsys_initcall(efi_runtime_map_init);
diff --git a/include/linux/efi.h b/include/linux/efi.h
index fb60b10..4f1651d 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -872,4 +872,10 @@ int efivars_sysfs_init(void);
#endif /* CONFIG_EFI_VARS */
+#ifdef CONFIG_EFI_RUNTIME_MAP
+extern void *efi_runtime_map;
+extern int nr_efi_runtime_map;
+extern struct kobject *efi_kobj;
+#endif
+
#endif /* _LINUX_EFI_H */
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.
Introducing a new directory /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap. Containing below attribute
in each file of that directory:
attribute num_pages phys_addr type virt_addr
Matt: s/efi-runtime-map.c/runtime-map.c
change dir name to runtime-map
update to use desc_size in efi_runtime_map
cleaup the code, add function efi_save_runtime_map
improve err handling
Matt: changelog fix;
Documentation fixes.
only export runtime-map sysfs file in case CONFIG_KEXEC
Add macros for sysfs _show functions
move functions to front of .c, remove forward declarations.
Boris: Documentation grammer/spelling fix
better error handling for krealloc
other code improvements.
move efi_runtime_map_init to subsys_initcall.
set efi_kobj = NULL in case efisubsys_init fails. And then efi_runtime_map_init
will bail out.
Kconfig EFI_RUNTIME_MAP depends on X86 && KEXEC && EFI
Signed-off-by: Dave Young <dyoung@redhat.com>
---
.../ABI/testing/sysfs-firmware-efi-runtime-map | 36 +++++
arch/x86/platform/efi/efi.c | 28 ++++
drivers/firmware/efi/Kconfig | 11 ++
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/efi.c | 4 +-
drivers/firmware/efi/runtime-map.c | 176 +++++++++++++++++++++
include/linux/efi.h | 6 +
7 files changed, 261 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
create mode 100644 drivers/firmware/efi/runtime-map.c
diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
new file mode 100644
index 0000000..2ab7dd2
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
@@ -0,0 +1,36 @@
+What: /sys/firmware/efi/runtime-map/
+Date: December 2013
+Contact: Dave Young <dyoung@redhat.com>
+Description:
+ Switching efi runtime services to virtual mode requires
+ that all efi memory ranges which have the runtime attribute
+ bit set to be mapped to virtual addresses.
+
+ The efi runtime services can only be switched to virtual
+ mode once without rebooting. The kexec kernel must maintain
+ the same physical to virtual address mappings as the first
+ kernel. The mappings are exported to sysfs so userspace tools
+ can reassemble them and pass them into the kexec kernel.
+
+ /sys/firmware/efi/runtime-map/ is the directory the kernel
+ exports that information in.
+
+ subdirectories are named with the number of the memory range:
+
+ /sys/firmware/efi/runtime-map/0
+ /sys/firmware/efi/runtime-map/1
+ /sys/firmware/efi/runtime-map/2
+ /sys/firmware/efi/runtime-map/3
+ ...
+
+ Each subdirectory contains five files:
+
+ attribute : The attributes of the memory range.
+ num_pages : The size of the memory range in pages.
+ phys_addr : The physical address of the memory range.
+ type : The type of the memory range.
+ virt_addr : The virtual address of the memory range.
+
+ Above values are all hexadecimal numbers with the '0x' prefix.
+
+Users: Kexec
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 3e8b760..8289e0c 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
{NULL_GUID, NULL, NULL},
};
+void *efi_runtime_map;
+int nr_efi_runtime_map;
+
/*
* Returns 1 if 'facility' is enabled, 0 otherwise.
*/
@@ -810,6 +813,19 @@ static void __init efi_merge_regions(void)
}
}
+static int __init save_runtime_map(efi_memory_desc_t *md, int idx)
+{
+ void *p;
+ p = krealloc(efi_runtime_map, (idx + 1) * memmap.desc_size, GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ efi_runtime_map = p;
+ memcpy(efi_runtime_map + idx * memmap.desc_size, md, memmap.desc_size);
+
+ return 0;
+}
+
/*
* Map efi memory ranges for runtime serivce and update new_memmap with virtual
* addresses.
@@ -820,6 +836,7 @@ static void * __init efi_map_regions(int *count)
void *p, *tmp, *new_memmap = NULL;
unsigned long size;
u64 end, systab;
+ int err = 0;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
@@ -848,10 +865,21 @@ static void * __init efi_map_regions(int *count)
new_memmap = tmp;
memcpy(new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
+ if (md->type != EFI_BOOT_SERVICES_CODE &&
+ md->type != EFI_BOOT_SERVICES_DATA) {
+ err = save_runtime_map(md, nr_efi_runtime_map);
+ if (err)
+ goto out_save_runtime;
+ nr_efi_runtime_map++;
+ }
(*count)++;
}
return new_memmap;
+out_save_runtime:
+ kfree(efi_runtime_map);
+ nr_efi_runtime_map = 0;
+ efi_runtime_map = NULL;
out_krealloc:
kfree(new_memmap);
return NULL;
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 3150aa4..3d8d6f6 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -39,4 +39,15 @@ config EFI_VARS_PSTORE_DEFAULT_DISABLE
config UEFI_CPER
def_bool n
+config EFI_RUNTIME_MAP
+ bool "Export efi runtime maps to sysfs" if EXPERT
+ depends on X86 && EFI && KEXEC
+ default y
+ help
+ Export efi runtime memory maps to /sys/firmware/efi/runtime-map.
+ That memory map is used for example by kexec to set up efi virtual
+ mapping the 2nd kernel, but can also be used for debugging purposes.
+
+ See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map.
+
endmenu
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 9ba156d..a58e0f1 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -5,3 +5,4 @@ obj-y += efi.o vars.o
obj-$(CONFIG_EFI_VARS) += efivars.o
obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o
obj-$(CONFIG_UEFI_CPER) += cper.o
+obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 0ecccab..0a288e3 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -38,7 +38,8 @@ struct efi __read_mostly efi = {
};
EXPORT_SYMBOL(efi);
-static struct kobject *efi_kobj;
+struct kobject *efi_kobj;
+EXPORT_SYMBOL_GPL(efi_kobj);
static struct kobject *efivars_kobj;
/*
@@ -183,6 +184,7 @@ err_unregister:
generic_ops_unregister();
err_put:
kobject_put(efi_kobj);
+ efi_kobj = NULL;
return error;
}
diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
new file mode 100644
index 0000000..e5e9984
--- /dev/null
+++ b/drivers/firmware/efi/runtime-map.c
@@ -0,0 +1,176 @@
+/*
+ * linux/drivers/efi/runtime-map.c
+ * Copyright (C) 2013 Red Hat, Inc., Dave Young <dyoung@redhat.com>
+ *
+ * This file is released under the GPLv2.
+ */
+
+#include <linux/string.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/efi.h>
+#include <linux/slab.h>
+
+#include <asm/setup.h>
+
+struct efi_runtime_map_entry {
+ efi_memory_desc_t md;
+ struct kobject kobj; /* kobject for each entry */
+};
+
+static struct efi_runtime_map_entry **map_entries;
+
+struct map_attribute {
+ struct attribute attr;
+ ssize_t (*show)(struct efi_runtime_map_entry *entry, char *buf);
+};
+
+static inline struct map_attribute *to_map_attr(struct attribute *attr)
+{
+ return container_of(attr, struct map_attribute, attr);
+}
+
+static ssize_t type_show(struct efi_runtime_map_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%x\n", entry->md.type);
+}
+
+#define EFI_RUNTIME_FIELD(var) entry->md.var
+
+#define EFI_RUNTIME_U64_ATTR_SHOW(name) \
+static ssize_t name##_show(struct efi_runtime_map_entry *entry, char *buf) \
+{ \
+ return snprintf(buf, PAGE_SIZE, "0x%llx\n", EFI_RUNTIME_FIELD(name)); \
+}
+
+EFI_RUNTIME_U64_ATTR_SHOW(phys_addr);
+EFI_RUNTIME_U64_ATTR_SHOW(virt_addr);
+EFI_RUNTIME_U64_ATTR_SHOW(num_pages);
+EFI_RUNTIME_U64_ATTR_SHOW(attribute);
+
+static inline struct efi_runtime_map_entry *to_map_entry(struct kobject *kobj)
+{
+ return container_of(kobj, struct efi_runtime_map_entry, kobj);
+}
+
+static ssize_t map_attr_show(struct kobject *kobj, struct attribute *attr,
+ char *buf)
+{
+ struct efi_runtime_map_entry *entry = to_map_entry(kobj);
+ struct map_attribute *map_attr = to_map_attr(attr);
+
+ return map_attr->show(entry, buf);
+}
+
+static struct map_attribute map_type_attr = __ATTR_RO(type);
+static struct map_attribute map_phys_addr_attr = __ATTR_RO(phys_addr);
+static struct map_attribute map_virt_addr_attr = __ATTR_RO(virt_addr);
+static struct map_attribute map_num_pages_attr = __ATTR_RO(num_pages);
+static struct map_attribute map_attribute_attr = __ATTR_RO(attribute);
+
+/*
+ * These are default attributes that are added for every memmap entry.
+ */
+static struct attribute *def_attrs[] = {
+ &map_type_attr.attr,
+ &map_phys_addr_attr.attr,
+ &map_virt_addr_attr.attr,
+ &map_num_pages_attr.attr,
+ &map_attribute_attr.attr,
+ NULL
+};
+
+static const struct sysfs_ops map_attr_ops = {
+ .show = map_attr_show,
+};
+
+static void map_release(struct kobject *kobj)
+{
+ struct efi_runtime_map_entry *entry;
+
+ entry = to_map_entry(kobj);
+ kfree(entry);
+}
+
+static struct kobj_type __refdata map_ktype = {
+ .sysfs_ops = &map_attr_ops,
+ .default_attrs = def_attrs,
+ .release = map_release,
+};
+
+static struct kset *map_kset;
+
+static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
+{
+ int ret;
+ struct efi_runtime_map_entry *entry;
+ struct efi_info *e = &boot_params.efi_info;
+
+ if (!map_kset) {
+ map_kset = kset_create_and_add("runtime-map", NULL,
+ efi_kobj);
+ if (!map_kset)
+ return ERR_PTR(-ENOMEM);
+ }
+
+ entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry) {
+ kset_unregister(map_kset);
+ return entry;
+ }
+
+ memcpy(&entry->md, efi_runtime_map + nr * e->efi_memdesc_size,
+ sizeof(efi_memory_desc_t));
+
+ kobject_init(&entry->kobj, &map_ktype);
+ entry->kobj.kset = map_kset;
+ ret = kobject_add(&entry->kobj, NULL, "%d", nr);
+ if (ret) {
+ kobject_put(&entry->kobj);
+ kset_unregister(map_kset);
+ return ERR_PTR(ret);
+ }
+
+ return entry;
+}
+
+static int __init efi_runtime_map_init(void)
+{
+ int i, j, ret = 0;
+ struct efi_runtime_map_entry *entry;
+
+ if (!efi_kobj)
+ return 0;
+
+ if (!efi_runtime_map)
+ return 0;
+
+ map_entries = kzalloc(nr_efi_runtime_map * sizeof(entry), GFP_KERNEL);
+ if (!map_entries) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ for (i = 0; i < nr_efi_runtime_map; i++) {
+ entry = add_sysfs_runtime_map_entry(i);
+ if (IS_ERR(entry)) {
+ ret = PTR_ERR(entry);
+ goto out_add_entry;
+ }
+ *(map_entries + i) = entry;
+ }
+
+ return 0;
+out_add_entry:
+ for (j = i - 1; j > 0; j--) {
+ entry = *(map_entries + j);
+ kobject_put(&entry->kobj);
+ }
+ if (map_kset)
+ kset_unregister(map_kset);
+out:
+ return ret;
+}
+
+subsys_initcall(efi_runtime_map_init);
diff --git a/include/linux/efi.h b/include/linux/efi.h
index fb60b10..4f1651d 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -872,4 +872,10 @@ int efivars_sysfs_init(void);
#endif /* CONFIG_EFI_VARS */
+#ifdef CONFIG_EFI_RUNTIME_MAP
+extern void *efi_runtime_map;
+extern int nr_efi_runtime_map;
+extern struct kobject *efi_kobj;
+#endif
+
#endif /* _LINUX_EFI_H */
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bp-Gina5bIWoIWzQB+pC5nmwQ, greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.
Introducing a new directory /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap. Containing below attribute
in each file of that directory:
attribute num_pages phys_addr type virt_addr
Matt: s/efi-runtime-map.c/runtime-map.c
change dir name to runtime-map
update to use desc_size in efi_runtime_map
cleaup the code, add function efi_save_runtime_map
improve err handling
Matt: changelog fix;
Documentation fixes.
only export runtime-map sysfs file in case CONFIG_KEXEC
Add macros for sysfs _show functions
move functions to front of .c, remove forward declarations.
Boris: Documentation grammer/spelling fix
better error handling for krealloc
other code improvements.
move efi_runtime_map_init to subsys_initcall.
set efi_kobj = NULL in case efisubsys_init fails. And then efi_runtime_map_init
will bail out.
Kconfig EFI_RUNTIME_MAP depends on X86 && KEXEC && EFI
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
.../ABI/testing/sysfs-firmware-efi-runtime-map | 36 +++++
arch/x86/platform/efi/efi.c | 28 ++++
drivers/firmware/efi/Kconfig | 11 ++
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/efi.c | 4 +-
drivers/firmware/efi/runtime-map.c | 176 +++++++++++++++++++++
include/linux/efi.h | 6 +
7 files changed, 261 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
create mode 100644 drivers/firmware/efi/runtime-map.c
diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
new file mode 100644
index 0000000..2ab7dd2
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
@@ -0,0 +1,36 @@
+What: /sys/firmware/efi/runtime-map/
+Date: December 2013
+Contact: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
+Description:
+ Switching efi runtime services to virtual mode requires
+ that all efi memory ranges which have the runtime attribute
+ bit set to be mapped to virtual addresses.
+
+ The efi runtime services can only be switched to virtual
+ mode once without rebooting. The kexec kernel must maintain
+ the same physical to virtual address mappings as the first
+ kernel. The mappings are exported to sysfs so userspace tools
+ can reassemble them and pass them into the kexec kernel.
+
+ /sys/firmware/efi/runtime-map/ is the directory the kernel
+ exports that information in.
+
+ subdirectories are named with the number of the memory range:
+
+ /sys/firmware/efi/runtime-map/0
+ /sys/firmware/efi/runtime-map/1
+ /sys/firmware/efi/runtime-map/2
+ /sys/firmware/efi/runtime-map/3
+ ...
+
+ Each subdirectory contains five files:
+
+ attribute : The attributes of the memory range.
+ num_pages : The size of the memory range in pages.
+ phys_addr : The physical address of the memory range.
+ type : The type of the memory range.
+ virt_addr : The virtual address of the memory range.
+
+ Above values are all hexadecimal numbers with the '0x' prefix.
+
+Users: Kexec
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 3e8b760..8289e0c 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
{NULL_GUID, NULL, NULL},
};
+void *efi_runtime_map;
+int nr_efi_runtime_map;
+
/*
* Returns 1 if 'facility' is enabled, 0 otherwise.
*/
@@ -810,6 +813,19 @@ static void __init efi_merge_regions(void)
}
}
+static int __init save_runtime_map(efi_memory_desc_t *md, int idx)
+{
+ void *p;
+ p = krealloc(efi_runtime_map, (idx + 1) * memmap.desc_size, GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ efi_runtime_map = p;
+ memcpy(efi_runtime_map + idx * memmap.desc_size, md, memmap.desc_size);
+
+ return 0;
+}
+
/*
* Map efi memory ranges for runtime serivce and update new_memmap with virtual
* addresses.
@@ -820,6 +836,7 @@ static void * __init efi_map_regions(int *count)
void *p, *tmp, *new_memmap = NULL;
unsigned long size;
u64 end, systab;
+ int err = 0;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
@@ -848,10 +865,21 @@ static void * __init efi_map_regions(int *count)
new_memmap = tmp;
memcpy(new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
+ if (md->type != EFI_BOOT_SERVICES_CODE &&
+ md->type != EFI_BOOT_SERVICES_DATA) {
+ err = save_runtime_map(md, nr_efi_runtime_map);
+ if (err)
+ goto out_save_runtime;
+ nr_efi_runtime_map++;
+ }
(*count)++;
}
return new_memmap;
+out_save_runtime:
+ kfree(efi_runtime_map);
+ nr_efi_runtime_map = 0;
+ efi_runtime_map = NULL;
out_krealloc:
kfree(new_memmap);
return NULL;
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 3150aa4..3d8d6f6 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -39,4 +39,15 @@ config EFI_VARS_PSTORE_DEFAULT_DISABLE
config UEFI_CPER
def_bool n
+config EFI_RUNTIME_MAP
+ bool "Export efi runtime maps to sysfs" if EXPERT
+ depends on X86 && EFI && KEXEC
+ default y
+ help
+ Export efi runtime memory maps to /sys/firmware/efi/runtime-map.
+ That memory map is used for example by kexec to set up efi virtual
+ mapping the 2nd kernel, but can also be used for debugging purposes.
+
+ See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map.
+
endmenu
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 9ba156d..a58e0f1 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -5,3 +5,4 @@ obj-y += efi.o vars.o
obj-$(CONFIG_EFI_VARS) += efivars.o
obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o
obj-$(CONFIG_UEFI_CPER) += cper.o
+obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 0ecccab..0a288e3 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -38,7 +38,8 @@ struct efi __read_mostly efi = {
};
EXPORT_SYMBOL(efi);
-static struct kobject *efi_kobj;
+struct kobject *efi_kobj;
+EXPORT_SYMBOL_GPL(efi_kobj);
static struct kobject *efivars_kobj;
/*
@@ -183,6 +184,7 @@ err_unregister:
generic_ops_unregister();
err_put:
kobject_put(efi_kobj);
+ efi_kobj = NULL;
return error;
}
diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
new file mode 100644
index 0000000..e5e9984
--- /dev/null
+++ b/drivers/firmware/efi/runtime-map.c
@@ -0,0 +1,176 @@
+/*
+ * linux/drivers/efi/runtime-map.c
+ * Copyright (C) 2013 Red Hat, Inc., Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
+ *
+ * This file is released under the GPLv2.
+ */
+
+#include <linux/string.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/efi.h>
+#include <linux/slab.h>
+
+#include <asm/setup.h>
+
+struct efi_runtime_map_entry {
+ efi_memory_desc_t md;
+ struct kobject kobj; /* kobject for each entry */
+};
+
+static struct efi_runtime_map_entry **map_entries;
+
+struct map_attribute {
+ struct attribute attr;
+ ssize_t (*show)(struct efi_runtime_map_entry *entry, char *buf);
+};
+
+static inline struct map_attribute *to_map_attr(struct attribute *attr)
+{
+ return container_of(attr, struct map_attribute, attr);
+}
+
+static ssize_t type_show(struct efi_runtime_map_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%x\n", entry->md.type);
+}
+
+#define EFI_RUNTIME_FIELD(var) entry->md.var
+
+#define EFI_RUNTIME_U64_ATTR_SHOW(name) \
+static ssize_t name##_show(struct efi_runtime_map_entry *entry, char *buf) \
+{ \
+ return snprintf(buf, PAGE_SIZE, "0x%llx\n", EFI_RUNTIME_FIELD(name)); \
+}
+
+EFI_RUNTIME_U64_ATTR_SHOW(phys_addr);
+EFI_RUNTIME_U64_ATTR_SHOW(virt_addr);
+EFI_RUNTIME_U64_ATTR_SHOW(num_pages);
+EFI_RUNTIME_U64_ATTR_SHOW(attribute);
+
+static inline struct efi_runtime_map_entry *to_map_entry(struct kobject *kobj)
+{
+ return container_of(kobj, struct efi_runtime_map_entry, kobj);
+}
+
+static ssize_t map_attr_show(struct kobject *kobj, struct attribute *attr,
+ char *buf)
+{
+ struct efi_runtime_map_entry *entry = to_map_entry(kobj);
+ struct map_attribute *map_attr = to_map_attr(attr);
+
+ return map_attr->show(entry, buf);
+}
+
+static struct map_attribute map_type_attr = __ATTR_RO(type);
+static struct map_attribute map_phys_addr_attr = __ATTR_RO(phys_addr);
+static struct map_attribute map_virt_addr_attr = __ATTR_RO(virt_addr);
+static struct map_attribute map_num_pages_attr = __ATTR_RO(num_pages);
+static struct map_attribute map_attribute_attr = __ATTR_RO(attribute);
+
+/*
+ * These are default attributes that are added for every memmap entry.
+ */
+static struct attribute *def_attrs[] = {
+ &map_type_attr.attr,
+ &map_phys_addr_attr.attr,
+ &map_virt_addr_attr.attr,
+ &map_num_pages_attr.attr,
+ &map_attribute_attr.attr,
+ NULL
+};
+
+static const struct sysfs_ops map_attr_ops = {
+ .show = map_attr_show,
+};
+
+static void map_release(struct kobject *kobj)
+{
+ struct efi_runtime_map_entry *entry;
+
+ entry = to_map_entry(kobj);
+ kfree(entry);
+}
+
+static struct kobj_type __refdata map_ktype = {
+ .sysfs_ops = &map_attr_ops,
+ .default_attrs = def_attrs,
+ .release = map_release,
+};
+
+static struct kset *map_kset;
+
+static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
+{
+ int ret;
+ struct efi_runtime_map_entry *entry;
+ struct efi_info *e = &boot_params.efi_info;
+
+ if (!map_kset) {
+ map_kset = kset_create_and_add("runtime-map", NULL,
+ efi_kobj);
+ if (!map_kset)
+ return ERR_PTR(-ENOMEM);
+ }
+
+ entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry) {
+ kset_unregister(map_kset);
+ return entry;
+ }
+
+ memcpy(&entry->md, efi_runtime_map + nr * e->efi_memdesc_size,
+ sizeof(efi_memory_desc_t));
+
+ kobject_init(&entry->kobj, &map_ktype);
+ entry->kobj.kset = map_kset;
+ ret = kobject_add(&entry->kobj, NULL, "%d", nr);
+ if (ret) {
+ kobject_put(&entry->kobj);
+ kset_unregister(map_kset);
+ return ERR_PTR(ret);
+ }
+
+ return entry;
+}
+
+static int __init efi_runtime_map_init(void)
+{
+ int i, j, ret = 0;
+ struct efi_runtime_map_entry *entry;
+
+ if (!efi_kobj)
+ return 0;
+
+ if (!efi_runtime_map)
+ return 0;
+
+ map_entries = kzalloc(nr_efi_runtime_map * sizeof(entry), GFP_KERNEL);
+ if (!map_entries) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ for (i = 0; i < nr_efi_runtime_map; i++) {
+ entry = add_sysfs_runtime_map_entry(i);
+ if (IS_ERR(entry)) {
+ ret = PTR_ERR(entry);
+ goto out_add_entry;
+ }
+ *(map_entries + i) = entry;
+ }
+
+ return 0;
+out_add_entry:
+ for (j = i - 1; j > 0; j--) {
+ entry = *(map_entries + j);
+ kobject_put(&entry->kobj);
+ }
+ if (map_kset)
+ kset_unregister(map_kset);
+out:
+ return ret;
+}
+
+subsys_initcall(efi_runtime_map_init);
diff --git a/include/linux/efi.h b/include/linux/efi.h
index fb60b10..4f1651d 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -872,4 +872,10 @@ int efivars_sysfs_init(void);
#endif /* CONFIG_EFI_VARS */
+#ifdef CONFIG_EFI_RUNTIME_MAP
+extern void *efi_runtime_map;
+extern int nr_efi_runtime_map;
+extern struct kobject *efi_kobj;
+#endif
+
#endif /* _LINUX_EFI_H */
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-11 18:55 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 18:55 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On Mon, Dec 09, 2013 at 05:42:21PM +0800, Dave Young wrote:
> kexec kernel will need exactly same mapping for
> efi runtime memory ranges. Thus here export the
> runtime ranges mapping to sysfs, kexec-tools
> will assemble them and pass to 2nd kernel via
> setup_data.
>
> Introducing a new directory /sys/firmware/efi/runtime-map
> Just like /sys/firmware/memmap. Containing below attribute
> in each file of that directory:
> attribute num_pages phys_addr type virt_addr
>
> Matt: s/efi-runtime-map.c/runtime-map.c
> change dir name to runtime-map
> update to use desc_size in efi_runtime_map
> cleaup the code, add function efi_save_runtime_map
> improve err handling
>
> Matt: changelog fix;
> Documentation fixes.
> only export runtime-map sysfs file in case CONFIG_KEXEC
> Add macros for sysfs _show functions
> move functions to front of .c, remove forward declarations.
>
> Boris: Documentation grammer/spelling fix
> better error handling for krealloc
> other code improvements.
> move efi_runtime_map_init to subsys_initcall.
> set efi_kobj = NULL in case efisubsys_init fails. And then efi_runtime_map_init
> will bail out.
> Kconfig EFI_RUNTIME_MAP depends on X86 && KEXEC && EFI
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> .../ABI/testing/sysfs-firmware-efi-runtime-map | 36 +++++
> arch/x86/platform/efi/efi.c | 28 ++++
> drivers/firmware/efi/Kconfig | 11 ++
> drivers/firmware/efi/Makefile | 1 +
> drivers/firmware/efi/efi.c | 4 +-
> drivers/firmware/efi/runtime-map.c | 176 +++++++++++++++++++++
> include/linux/efi.h | 6 +
> 7 files changed, 261 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> create mode 100644 drivers/firmware/efi/runtime-map.c
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> new file mode 100644
> index 0000000..2ab7dd2
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> @@ -0,0 +1,36 @@
> +What: /sys/firmware/efi/runtime-map/
> +Date: December 2013
> +Contact: Dave Young <dyoung@redhat.com>
> +Description:
This could start at the same line as Description
> + Switching efi runtime services to virtual mode requires
> + that all efi memory ranges which have the runtime attribute
> + bit set to be mapped to virtual addresses.
> +
> + The efi runtime services can only be switched to virtual
> + mode once without rebooting. The kexec kernel must maintain
> + the same physical to virtual address mappings as the first
> + kernel. The mappings are exported to sysfs so userspace tools
> + can reassemble them and pass them into the kexec kernel.
> +
> + /sys/firmware/efi/runtime-map/ is the directory the kernel
> + exports that information in.
> +
> + subdirectories are named with the number of the memory range:
> +
> + /sys/firmware/efi/runtime-map/0
> + /sys/firmware/efi/runtime-map/1
> + /sys/firmware/efi/runtime-map/2
> + /sys/firmware/efi/runtime-map/3
> + ...
> +
> + Each subdirectory contains five files:
> +
> + attribute : The attributes of the memory range.
> + num_pages : The size of the memory range in pages.
> + phys_addr : The physical address of the memory range.
> + type : The type of the memory range.
> + virt_addr : The virtual address of the memory range.
> +
> + Above values are all hexadecimal numbers with the '0x' prefix.
> +
Superfluous newline.
> +Users: Kexec
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 3e8b760..8289e0c 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> {NULL_GUID, NULL, NULL},
> };
>
> +void *efi_runtime_map;
> +int nr_efi_runtime_map;
> +
> /*
> * Returns 1 if 'facility' is enabled, 0 otherwise.
> */
> @@ -810,6 +813,19 @@ static void __init efi_merge_regions(void)
> }
> }
>
> +static int __init save_runtime_map(efi_memory_desc_t *md, int idx)
> +{
> + void *p;
> + p = krealloc(efi_runtime_map, (idx + 1) * memmap.desc_size, GFP_KERNEL);
> + if (!p)
> + return -ENOMEM;
> +
> + efi_runtime_map = p;
> + memcpy(efi_runtime_map + idx * memmap.desc_size, md, memmap.desc_size);
> +
> + return 0;
> +}
> +
> /*
> * Map efi memory ranges for runtime serivce and update new_memmap with virtual
> * addresses.
> @@ -820,6 +836,7 @@ static void * __init efi_map_regions(int *count)
> void *p, *tmp, *new_memmap = NULL;
> unsigned long size;
> u64 end, systab;
> + int err = 0;
>
> for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> md = p;
> @@ -848,10 +865,21 @@ static void * __init efi_map_regions(int *count)
> new_memmap = tmp;
> memcpy(new_memmap + (*count * memmap.desc_size), md,
> memmap.desc_size);
> + if (md->type != EFI_BOOT_SERVICES_CODE &&
> + md->type != EFI_BOOT_SERVICES_DATA) {
> + err = save_runtime_map(md, nr_efi_runtime_map);
> + if (err)
> + goto out_save_runtime;
> + nr_efi_runtime_map++;
> + }
So why don't you move that code to save_runtime_map?
It would looks like this:
...
new_memmap = tmp;
memcpy(new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
save_runtime_map(md);
(*count)++;
[nr_efi_runtime_map is global, no need to pass it to save_runtime_map() ]
and the EFI_BOOT* tests can be done in save_runtime_map and also the
error handling can happen there. This way efi_map_regions() won't
need to know about anything. This way, you can later move the whole
save_runtime_map() function to efi-kexec.c just by taking it without any
need for untangling.
> +out_save_runtime:
> + kfree(efi_runtime_map);
> + nr_efi_runtime_map = 0;
> + efi_runtime_map = NULL;
This can go there too.
> out_krealloc:
> kfree(new_memmap);
> return NULL;
> diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> index 3150aa4..3d8d6f6 100644
> --- a/drivers/firmware/efi/Kconfig
> +++ b/drivers/firmware/efi/Kconfig
> @@ -39,4 +39,15 @@ config EFI_VARS_PSTORE_DEFAULT_DISABLE
> config UEFI_CPER
> def_bool n
>
> +config EFI_RUNTIME_MAP
> + bool "Export efi runtime maps to sysfs" if EXPERT
What's with the EXPERT? It depends on KEXEC already.
> + depends on X86 && EFI && KEXEC
> + default y
> + help
> + Export efi runtime memory maps to /sys/firmware/efi/runtime-map.
> + That memory map is used for example by kexec to set up efi virtual
> + mapping the 2nd kernel, but can also be used for debugging purposes.
> +
> + See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map.
> +
> endmenu
...
> +static int __init efi_runtime_map_init(void)
> +{
> + int i, j, ret = 0;
> + struct efi_runtime_map_entry *entry;
> +
> + if (!efi_kobj)
> + return 0;
> +
> + if (!efi_runtime_map)
> + return 0;
> +
> + map_entries = kzalloc(nr_efi_runtime_map * sizeof(entry), GFP_KERNEL);
> + if (!map_entries) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + for (i = 0; i < nr_efi_runtime_map; i++) {
> + entry = add_sysfs_runtime_map_entry(i);
> + if (IS_ERR(entry)) {
> + ret = PTR_ERR(entry);
> + goto out_add_entry;
> + }
> + *(map_entries + i) = entry;
> + }
> +
> + return 0;
> +out_add_entry:
> + for (j = i - 1; j > 0; j--) {
> + entry = *(map_entries + j);
> + kobject_put(&entry->kobj);
> + }
> + if (map_kset)
> + kset_unregister(map_kset);
> +out:
> + return ret;
> +}
> +
> +subsys_initcall(efi_runtime_map_init);
Let me repeat myself:
Why an initcall? Can't we run this from efisubsys_init()?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-11 18:55 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 18:55 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On Mon, Dec 09, 2013 at 05:42:21PM +0800, Dave Young wrote:
> kexec kernel will need exactly same mapping for
> efi runtime memory ranges. Thus here export the
> runtime ranges mapping to sysfs, kexec-tools
> will assemble them and pass to 2nd kernel via
> setup_data.
>
> Introducing a new directory /sys/firmware/efi/runtime-map
> Just like /sys/firmware/memmap. Containing below attribute
> in each file of that directory:
> attribute num_pages phys_addr type virt_addr
>
> Matt: s/efi-runtime-map.c/runtime-map.c
> change dir name to runtime-map
> update to use desc_size in efi_runtime_map
> cleaup the code, add function efi_save_runtime_map
> improve err handling
>
> Matt: changelog fix;
> Documentation fixes.
> only export runtime-map sysfs file in case CONFIG_KEXEC
> Add macros for sysfs _show functions
> move functions to front of .c, remove forward declarations.
>
> Boris: Documentation grammer/spelling fix
> better error handling for krealloc
> other code improvements.
> move efi_runtime_map_init to subsys_initcall.
> set efi_kobj = NULL in case efisubsys_init fails. And then efi_runtime_map_init
> will bail out.
> Kconfig EFI_RUNTIME_MAP depends on X86 && KEXEC && EFI
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> .../ABI/testing/sysfs-firmware-efi-runtime-map | 36 +++++
> arch/x86/platform/efi/efi.c | 28 ++++
> drivers/firmware/efi/Kconfig | 11 ++
> drivers/firmware/efi/Makefile | 1 +
> drivers/firmware/efi/efi.c | 4 +-
> drivers/firmware/efi/runtime-map.c | 176 +++++++++++++++++++++
> include/linux/efi.h | 6 +
> 7 files changed, 261 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> create mode 100644 drivers/firmware/efi/runtime-map.c
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> new file mode 100644
> index 0000000..2ab7dd2
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> @@ -0,0 +1,36 @@
> +What: /sys/firmware/efi/runtime-map/
> +Date: December 2013
> +Contact: Dave Young <dyoung@redhat.com>
> +Description:
This could start at the same line as Description
> + Switching efi runtime services to virtual mode requires
> + that all efi memory ranges which have the runtime attribute
> + bit set to be mapped to virtual addresses.
> +
> + The efi runtime services can only be switched to virtual
> + mode once without rebooting. The kexec kernel must maintain
> + the same physical to virtual address mappings as the first
> + kernel. The mappings are exported to sysfs so userspace tools
> + can reassemble them and pass them into the kexec kernel.
> +
> + /sys/firmware/efi/runtime-map/ is the directory the kernel
> + exports that information in.
> +
> + subdirectories are named with the number of the memory range:
> +
> + /sys/firmware/efi/runtime-map/0
> + /sys/firmware/efi/runtime-map/1
> + /sys/firmware/efi/runtime-map/2
> + /sys/firmware/efi/runtime-map/3
> + ...
> +
> + Each subdirectory contains five files:
> +
> + attribute : The attributes of the memory range.
> + num_pages : The size of the memory range in pages.
> + phys_addr : The physical address of the memory range.
> + type : The type of the memory range.
> + virt_addr : The virtual address of the memory range.
> +
> + Above values are all hexadecimal numbers with the '0x' prefix.
> +
Superfluous newline.
> +Users: Kexec
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 3e8b760..8289e0c 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> {NULL_GUID, NULL, NULL},
> };
>
> +void *efi_runtime_map;
> +int nr_efi_runtime_map;
> +
> /*
> * Returns 1 if 'facility' is enabled, 0 otherwise.
> */
> @@ -810,6 +813,19 @@ static void __init efi_merge_regions(void)
> }
> }
>
> +static int __init save_runtime_map(efi_memory_desc_t *md, int idx)
> +{
> + void *p;
> + p = krealloc(efi_runtime_map, (idx + 1) * memmap.desc_size, GFP_KERNEL);
> + if (!p)
> + return -ENOMEM;
> +
> + efi_runtime_map = p;
> + memcpy(efi_runtime_map + idx * memmap.desc_size, md, memmap.desc_size);
> +
> + return 0;
> +}
> +
> /*
> * Map efi memory ranges for runtime serivce and update new_memmap with virtual
> * addresses.
> @@ -820,6 +836,7 @@ static void * __init efi_map_regions(int *count)
> void *p, *tmp, *new_memmap = NULL;
> unsigned long size;
> u64 end, systab;
> + int err = 0;
>
> for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> md = p;
> @@ -848,10 +865,21 @@ static void * __init efi_map_regions(int *count)
> new_memmap = tmp;
> memcpy(new_memmap + (*count * memmap.desc_size), md,
> memmap.desc_size);
> + if (md->type != EFI_BOOT_SERVICES_CODE &&
> + md->type != EFI_BOOT_SERVICES_DATA) {
> + err = save_runtime_map(md, nr_efi_runtime_map);
> + if (err)
> + goto out_save_runtime;
> + nr_efi_runtime_map++;
> + }
So why don't you move that code to save_runtime_map?
It would looks like this:
...
new_memmap = tmp;
memcpy(new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
save_runtime_map(md);
(*count)++;
[nr_efi_runtime_map is global, no need to pass it to save_runtime_map() ]
and the EFI_BOOT* tests can be done in save_runtime_map and also the
error handling can happen there. This way efi_map_regions() won't
need to know about anything. This way, you can later move the whole
save_runtime_map() function to efi-kexec.c just by taking it without any
need for untangling.
> +out_save_runtime:
> + kfree(efi_runtime_map);
> + nr_efi_runtime_map = 0;
> + efi_runtime_map = NULL;
This can go there too.
> out_krealloc:
> kfree(new_memmap);
> return NULL;
> diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> index 3150aa4..3d8d6f6 100644
> --- a/drivers/firmware/efi/Kconfig
> +++ b/drivers/firmware/efi/Kconfig
> @@ -39,4 +39,15 @@ config EFI_VARS_PSTORE_DEFAULT_DISABLE
> config UEFI_CPER
> def_bool n
>
> +config EFI_RUNTIME_MAP
> + bool "Export efi runtime maps to sysfs" if EXPERT
What's with the EXPERT? It depends on KEXEC already.
> + depends on X86 && EFI && KEXEC
> + default y
> + help
> + Export efi runtime memory maps to /sys/firmware/efi/runtime-map.
> + That memory map is used for example by kexec to set up efi virtual
> + mapping the 2nd kernel, but can also be used for debugging purposes.
> +
> + See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map.
> +
> endmenu
...
> +static int __init efi_runtime_map_init(void)
> +{
> + int i, j, ret = 0;
> + struct efi_runtime_map_entry *entry;
> +
> + if (!efi_kobj)
> + return 0;
> +
> + if (!efi_runtime_map)
> + return 0;
> +
> + map_entries = kzalloc(nr_efi_runtime_map * sizeof(entry), GFP_KERNEL);
> + if (!map_entries) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + for (i = 0; i < nr_efi_runtime_map; i++) {
> + entry = add_sysfs_runtime_map_entry(i);
> + if (IS_ERR(entry)) {
> + ret = PTR_ERR(entry);
> + goto out_add_entry;
> + }
> + *(map_entries + i) = entry;
> + }
> +
> + return 0;
> +out_add_entry:
> + for (j = i - 1; j > 0; j--) {
> + entry = *(map_entries + j);
> + kobject_put(&entry->kobj);
> + }
> + if (map_kset)
> + kset_unregister(map_kset);
> +out:
> + return ret;
> +}
> +
> +subsys_initcall(efi_runtime_map_init);
Let me repeat myself:
Why an initcall? Can't we run this from efisubsys_init()?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-11 18:55 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 18:55 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On Mon, Dec 09, 2013 at 05:42:21PM +0800, Dave Young wrote:
> kexec kernel will need exactly same mapping for
> efi runtime memory ranges. Thus here export the
> runtime ranges mapping to sysfs, kexec-tools
> will assemble them and pass to 2nd kernel via
> setup_data.
>
> Introducing a new directory /sys/firmware/efi/runtime-map
> Just like /sys/firmware/memmap. Containing below attribute
> in each file of that directory:
> attribute num_pages phys_addr type virt_addr
>
> Matt: s/efi-runtime-map.c/runtime-map.c
> change dir name to runtime-map
> update to use desc_size in efi_runtime_map
> cleaup the code, add function efi_save_runtime_map
> improve err handling
>
> Matt: changelog fix;
> Documentation fixes.
> only export runtime-map sysfs file in case CONFIG_KEXEC
> Add macros for sysfs _show functions
> move functions to front of .c, remove forward declarations.
>
> Boris: Documentation grammer/spelling fix
> better error handling for krealloc
> other code improvements.
> move efi_runtime_map_init to subsys_initcall.
> set efi_kobj = NULL in case efisubsys_init fails. And then efi_runtime_map_init
> will bail out.
> Kconfig EFI_RUNTIME_MAP depends on X86 && KEXEC && EFI
>
> Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> .../ABI/testing/sysfs-firmware-efi-runtime-map | 36 +++++
> arch/x86/platform/efi/efi.c | 28 ++++
> drivers/firmware/efi/Kconfig | 11 ++
> drivers/firmware/efi/Makefile | 1 +
> drivers/firmware/efi/efi.c | 4 +-
> drivers/firmware/efi/runtime-map.c | 176 +++++++++++++++++++++
> include/linux/efi.h | 6 +
> 7 files changed, 261 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> create mode 100644 drivers/firmware/efi/runtime-map.c
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> new file mode 100644
> index 0000000..2ab7dd2
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> @@ -0,0 +1,36 @@
> +What: /sys/firmware/efi/runtime-map/
> +Date: December 2013
> +Contact: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> +Description:
This could start at the same line as Description
> + Switching efi runtime services to virtual mode requires
> + that all efi memory ranges which have the runtime attribute
> + bit set to be mapped to virtual addresses.
> +
> + The efi runtime services can only be switched to virtual
> + mode once without rebooting. The kexec kernel must maintain
> + the same physical to virtual address mappings as the first
> + kernel. The mappings are exported to sysfs so userspace tools
> + can reassemble them and pass them into the kexec kernel.
> +
> + /sys/firmware/efi/runtime-map/ is the directory the kernel
> + exports that information in.
> +
> + subdirectories are named with the number of the memory range:
> +
> + /sys/firmware/efi/runtime-map/0
> + /sys/firmware/efi/runtime-map/1
> + /sys/firmware/efi/runtime-map/2
> + /sys/firmware/efi/runtime-map/3
> + ...
> +
> + Each subdirectory contains five files:
> +
> + attribute : The attributes of the memory range.
> + num_pages : The size of the memory range in pages.
> + phys_addr : The physical address of the memory range.
> + type : The type of the memory range.
> + virt_addr : The virtual address of the memory range.
> +
> + Above values are all hexadecimal numbers with the '0x' prefix.
> +
Superfluous newline.
> +Users: Kexec
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 3e8b760..8289e0c 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> {NULL_GUID, NULL, NULL},
> };
>
> +void *efi_runtime_map;
> +int nr_efi_runtime_map;
> +
> /*
> * Returns 1 if 'facility' is enabled, 0 otherwise.
> */
> @@ -810,6 +813,19 @@ static void __init efi_merge_regions(void)
> }
> }
>
> +static int __init save_runtime_map(efi_memory_desc_t *md, int idx)
> +{
> + void *p;
> + p = krealloc(efi_runtime_map, (idx + 1) * memmap.desc_size, GFP_KERNEL);
> + if (!p)
> + return -ENOMEM;
> +
> + efi_runtime_map = p;
> + memcpy(efi_runtime_map + idx * memmap.desc_size, md, memmap.desc_size);
> +
> + return 0;
> +}
> +
> /*
> * Map efi memory ranges for runtime serivce and update new_memmap with virtual
> * addresses.
> @@ -820,6 +836,7 @@ static void * __init efi_map_regions(int *count)
> void *p, *tmp, *new_memmap = NULL;
> unsigned long size;
> u64 end, systab;
> + int err = 0;
>
> for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> md = p;
> @@ -848,10 +865,21 @@ static void * __init efi_map_regions(int *count)
> new_memmap = tmp;
> memcpy(new_memmap + (*count * memmap.desc_size), md,
> memmap.desc_size);
> + if (md->type != EFI_BOOT_SERVICES_CODE &&
> + md->type != EFI_BOOT_SERVICES_DATA) {
> + err = save_runtime_map(md, nr_efi_runtime_map);
> + if (err)
> + goto out_save_runtime;
> + nr_efi_runtime_map++;
> + }
So why don't you move that code to save_runtime_map?
It would looks like this:
...
new_memmap = tmp;
memcpy(new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
save_runtime_map(md);
(*count)++;
[nr_efi_runtime_map is global, no need to pass it to save_runtime_map() ]
and the EFI_BOOT* tests can be done in save_runtime_map and also the
error handling can happen there. This way efi_map_regions() won't
need to know about anything. This way, you can later move the whole
save_runtime_map() function to efi-kexec.c just by taking it without any
need for untangling.
> +out_save_runtime:
> + kfree(efi_runtime_map);
> + nr_efi_runtime_map = 0;
> + efi_runtime_map = NULL;
This can go there too.
> out_krealloc:
> kfree(new_memmap);
> return NULL;
> diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> index 3150aa4..3d8d6f6 100644
> --- a/drivers/firmware/efi/Kconfig
> +++ b/drivers/firmware/efi/Kconfig
> @@ -39,4 +39,15 @@ config EFI_VARS_PSTORE_DEFAULT_DISABLE
> config UEFI_CPER
> def_bool n
>
> +config EFI_RUNTIME_MAP
> + bool "Export efi runtime maps to sysfs" if EXPERT
What's with the EXPERT? It depends on KEXEC already.
> + depends on X86 && EFI && KEXEC
> + default y
> + help
> + Export efi runtime memory maps to /sys/firmware/efi/runtime-map.
> + That memory map is used for example by kexec to set up efi virtual
> + mapping the 2nd kernel, but can also be used for debugging purposes.
> +
> + See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map.
> +
> endmenu
...
> +static int __init efi_runtime_map_init(void)
> +{
> + int i, j, ret = 0;
> + struct efi_runtime_map_entry *entry;
> +
> + if (!efi_kobj)
> + return 0;
> +
> + if (!efi_runtime_map)
> + return 0;
> +
> + map_entries = kzalloc(nr_efi_runtime_map * sizeof(entry), GFP_KERNEL);
> + if (!map_entries) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + for (i = 0; i < nr_efi_runtime_map; i++) {
> + entry = add_sysfs_runtime_map_entry(i);
> + if (IS_ERR(entry)) {
> + ret = PTR_ERR(entry);
> + goto out_add_entry;
> + }
> + *(map_entries + i) = entry;
> + }
> +
> + return 0;
> +out_add_entry:
> + for (j = i - 1; j > 0; j--) {
> + entry = *(map_entries + j);
> + kobject_put(&entry->kobj);
> + }
> + if (map_kset)
> + kset_unregister(map_kset);
> +out:
> + return ret;
> +}
> +
> +subsys_initcall(efi_runtime_map_init);
Let me repeat myself:
Why an initcall? Can't we run this from efisubsys_init()?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-12 2:36 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:36 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
> > +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> > @@ -0,0 +1,36 @@
> > +What: /sys/firmware/efi/runtime-map/
> > +Date: December 2013
> > +Contact: Dave Young <dyoung@redhat.com>
> > +Description:
>
> This could start at the same line as Description
Ok.
[snip]
> > +
> > + Above values are all hexadecimal numbers with the '0x' prefix.
> > +
>
> Superfluous newline.
Will remove
>
> > +Users: Kexec
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 3e8b760..8289e0c 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> > {NULL_GUID, NULL, NULL},
> > };
> >
> > +void *efi_runtime_map;
> > +int nr_efi_runtime_map;
> > +
> > /*
> > * Returns 1 if 'facility' is enabled, 0 otherwise.
> > */
> > @@ -810,6 +813,19 @@ static void __init efi_merge_regions(void)
> > }
> > }
> >
> > +static int __init save_runtime_map(efi_memory_desc_t *md, int idx)
> > +{
> > + void *p;
> > + p = krealloc(efi_runtime_map, (idx + 1) * memmap.desc_size, GFP_KERNEL);
> > + if (!p)
> > + return -ENOMEM;
> > +
> > + efi_runtime_map = p;
> > + memcpy(efi_runtime_map + idx * memmap.desc_size, md, memmap.desc_size);
> > +
> > + return 0;
> > +}
> > +
> > /*
> > * Map efi memory ranges for runtime serivce and update new_memmap with virtual
> > * addresses.
> > @@ -820,6 +836,7 @@ static void * __init efi_map_regions(int *count)
> > void *p, *tmp, *new_memmap = NULL;
> > unsigned long size;
> > u64 end, systab;
> > + int err = 0;
> >
> > for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> > md = p;
> > @@ -848,10 +865,21 @@ static void * __init efi_map_regions(int *count)
> > new_memmap = tmp;
> > memcpy(new_memmap + (*count * memmap.desc_size), md,
> > memmap.desc_size);
> > + if (md->type != EFI_BOOT_SERVICES_CODE &&
> > + md->type != EFI_BOOT_SERVICES_DATA) {
> > + err = save_runtime_map(md, nr_efi_runtime_map);
> > + if (err)
> > + goto out_save_runtime;
> > + nr_efi_runtime_map++;
> > + }
>
> So why don't you move that code to save_runtime_map?
>
>
> It would looks like this:
>
> ...
> new_memmap = tmp;
> memcpy(new_memmap + (*count * memmap.desc_size), md,
> memmap.desc_size);
>
> save_runtime_map(md);
> (*count)++;
>
> [nr_efi_runtime_map is global, no need to pass it to save_runtime_map() ]
nr_efi_runtime_map is handled in diffrent way for 1st kernel and kexec kernel
For 1st kernel (boot from firmware) it's increased one by one in above function.
But for kexec kernel it is directly calculated from setup_data array len.
And increasing nr_efi_runtime_map in save_runtime_map is not ok the main reason
is I need the value firstly for the loop counter max value like below:
static int __init map_regions_fixed(void)
{
[snip]
for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
[snip]
save_runtime_map(md, i);
[snip]
}
>
> and the EFI_BOOT* tests can be done in save_runtime_map and also the
> error handling can happen there. This way efi_map_regions() won't
> need to know about anything. This way, you can later move the whole
> save_runtime_map() function to efi-kexec.c just by taking it without any
> need for untangling.
>
> > +out_save_runtime:
> > + kfree(efi_runtime_map);
> > + nr_efi_runtime_map = 0;
> > + efi_runtime_map = NULL;
>
> This can go there too.
This section can go the save_runtime_map but it looks clearer to put them here.
>
> > out_krealloc:
> > kfree(new_memmap);
> > return NULL;
> > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> > index 3150aa4..3d8d6f6 100644
> > --- a/drivers/firmware/efi/Kconfig
> > +++ b/drivers/firmware/efi/Kconfig
> > @@ -39,4 +39,15 @@ config EFI_VARS_PSTORE_DEFAULT_DISABLE
> > config UEFI_CPER
> > def_bool n
> >
> > +config EFI_RUNTIME_MAP
> > + bool "Export efi runtime maps to sysfs" if EXPERT
>
> What's with the EXPERT? It depends on KEXEC already.
EXPERT can be removed safely, will do.
>
> > + depends on X86 && EFI && KEXEC
> > + default y
> > + help
> > + Export efi runtime memory maps to /sys/firmware/efi/runtime-map.
> > + That memory map is used for example by kexec to set up efi virtual
> > + mapping the 2nd kernel, but can also be used for debugging purposes.
> > +
> > + See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map.
> > +
> > endmenu
>
> ...
>
> > +static int __init efi_runtime_map_init(void)
> > +{
> > + int i, j, ret = 0;
> > + struct efi_runtime_map_entry *entry;
> > +
> > + if (!efi_kobj)
> > + return 0;
> > +
> > + if (!efi_runtime_map)
> > + return 0;
> > +
> > + map_entries = kzalloc(nr_efi_runtime_map * sizeof(entry), GFP_KERNEL);
> > + if (!map_entries) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > +
> > + for (i = 0; i < nr_efi_runtime_map; i++) {
> > + entry = add_sysfs_runtime_map_entry(i);
> > + if (IS_ERR(entry)) {
> > + ret = PTR_ERR(entry);
> > + goto out_add_entry;
> > + }
> > + *(map_entries + i) = entry;
> > + }
> > +
> > + return 0;
> > +out_add_entry:
> > + for (j = i - 1; j > 0; j--) {
> > + entry = *(map_entries + j);
> > + kobject_put(&entry->kobj);
> > + }
> > + if (map_kset)
> > + kset_unregister(map_kset);
> > +out:
> > + return ret;
> > +}
> > +
> > +subsys_initcall(efi_runtime_map_init);
>
> Let me repeat myself:
>
> Why an initcall? Can't we run this from efisubsys_init()?
Sorry that I forgot to explain this in changelog, should ask you before.
I did try moving it to efisubsys_init but it need add extern declaration
for efi_runtime_map_init. Since link order will ensure it being called after
efisubsys_init I think it's fine with this static function.
--
Thanks for review
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-12 2:36 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:36 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
> > +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> > @@ -0,0 +1,36 @@
> > +What: /sys/firmware/efi/runtime-map/
> > +Date: December 2013
> > +Contact: Dave Young <dyoung@redhat.com>
> > +Description:
>
> This could start at the same line as Description
Ok.
[snip]
> > +
> > + Above values are all hexadecimal numbers with the '0x' prefix.
> > +
>
> Superfluous newline.
Will remove
>
> > +Users: Kexec
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 3e8b760..8289e0c 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> > {NULL_GUID, NULL, NULL},
> > };
> >
> > +void *efi_runtime_map;
> > +int nr_efi_runtime_map;
> > +
> > /*
> > * Returns 1 if 'facility' is enabled, 0 otherwise.
> > */
> > @@ -810,6 +813,19 @@ static void __init efi_merge_regions(void)
> > }
> > }
> >
> > +static int __init save_runtime_map(efi_memory_desc_t *md, int idx)
> > +{
> > + void *p;
> > + p = krealloc(efi_runtime_map, (idx + 1) * memmap.desc_size, GFP_KERNEL);
> > + if (!p)
> > + return -ENOMEM;
> > +
> > + efi_runtime_map = p;
> > + memcpy(efi_runtime_map + idx * memmap.desc_size, md, memmap.desc_size);
> > +
> > + return 0;
> > +}
> > +
> > /*
> > * Map efi memory ranges for runtime serivce and update new_memmap with virtual
> > * addresses.
> > @@ -820,6 +836,7 @@ static void * __init efi_map_regions(int *count)
> > void *p, *tmp, *new_memmap = NULL;
> > unsigned long size;
> > u64 end, systab;
> > + int err = 0;
> >
> > for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> > md = p;
> > @@ -848,10 +865,21 @@ static void * __init efi_map_regions(int *count)
> > new_memmap = tmp;
> > memcpy(new_memmap + (*count * memmap.desc_size), md,
> > memmap.desc_size);
> > + if (md->type != EFI_BOOT_SERVICES_CODE &&
> > + md->type != EFI_BOOT_SERVICES_DATA) {
> > + err = save_runtime_map(md, nr_efi_runtime_map);
> > + if (err)
> > + goto out_save_runtime;
> > + nr_efi_runtime_map++;
> > + }
>
> So why don't you move that code to save_runtime_map?
>
>
> It would looks like this:
>
> ...
> new_memmap = tmp;
> memcpy(new_memmap + (*count * memmap.desc_size), md,
> memmap.desc_size);
>
> save_runtime_map(md);
> (*count)++;
>
> [nr_efi_runtime_map is global, no need to pass it to save_runtime_map() ]
nr_efi_runtime_map is handled in diffrent way for 1st kernel and kexec kernel
For 1st kernel (boot from firmware) it's increased one by one in above function.
But for kexec kernel it is directly calculated from setup_data array len.
And increasing nr_efi_runtime_map in save_runtime_map is not ok the main reason
is I need the value firstly for the loop counter max value like below:
static int __init map_regions_fixed(void)
{
[snip]
for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
[snip]
save_runtime_map(md, i);
[snip]
}
>
> and the EFI_BOOT* tests can be done in save_runtime_map and also the
> error handling can happen there. This way efi_map_regions() won't
> need to know about anything. This way, you can later move the whole
> save_runtime_map() function to efi-kexec.c just by taking it without any
> need for untangling.
>
> > +out_save_runtime:
> > + kfree(efi_runtime_map);
> > + nr_efi_runtime_map = 0;
> > + efi_runtime_map = NULL;
>
> This can go there too.
This section can go the save_runtime_map but it looks clearer to put them here.
>
> > out_krealloc:
> > kfree(new_memmap);
> > return NULL;
> > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> > index 3150aa4..3d8d6f6 100644
> > --- a/drivers/firmware/efi/Kconfig
> > +++ b/drivers/firmware/efi/Kconfig
> > @@ -39,4 +39,15 @@ config EFI_VARS_PSTORE_DEFAULT_DISABLE
> > config UEFI_CPER
> > def_bool n
> >
> > +config EFI_RUNTIME_MAP
> > + bool "Export efi runtime maps to sysfs" if EXPERT
>
> What's with the EXPERT? It depends on KEXEC already.
EXPERT can be removed safely, will do.
>
> > + depends on X86 && EFI && KEXEC
> > + default y
> > + help
> > + Export efi runtime memory maps to /sys/firmware/efi/runtime-map.
> > + That memory map is used for example by kexec to set up efi virtual
> > + mapping the 2nd kernel, but can also be used for debugging purposes.
> > +
> > + See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map.
> > +
> > endmenu
>
> ...
>
> > +static int __init efi_runtime_map_init(void)
> > +{
> > + int i, j, ret = 0;
> > + struct efi_runtime_map_entry *entry;
> > +
> > + if (!efi_kobj)
> > + return 0;
> > +
> > + if (!efi_runtime_map)
> > + return 0;
> > +
> > + map_entries = kzalloc(nr_efi_runtime_map * sizeof(entry), GFP_KERNEL);
> > + if (!map_entries) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > +
> > + for (i = 0; i < nr_efi_runtime_map; i++) {
> > + entry = add_sysfs_runtime_map_entry(i);
> > + if (IS_ERR(entry)) {
> > + ret = PTR_ERR(entry);
> > + goto out_add_entry;
> > + }
> > + *(map_entries + i) = entry;
> > + }
> > +
> > + return 0;
> > +out_add_entry:
> > + for (j = i - 1; j > 0; j--) {
> > + entry = *(map_entries + j);
> > + kobject_put(&entry->kobj);
> > + }
> > + if (map_kset)
> > + kset_unregister(map_kset);
> > +out:
> > + return ret;
> > +}
> > +
> > +subsys_initcall(efi_runtime_map_init);
>
> Let me repeat myself:
>
> Why an initcall? Can't we run this from efisubsys_init()?
Sorry that I forgot to explain this in changelog, should ask you before.
I did try moving it to efisubsys_init but it need add extern declaration
for efi_runtime_map_init. Since link order will ensure it being called after
efisubsys_init I think it's fine with this static function.
--
Thanks for review
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-12 2:36 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:36 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
hpa-YMNOUZJC4hwAvxtiuMwx3w, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
> > +++ b/Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
> > @@ -0,0 +1,36 @@
> > +What: /sys/firmware/efi/runtime-map/
> > +Date: December 2013
> > +Contact: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > +Description:
>
> This could start at the same line as Description
Ok.
[snip]
> > +
> > + Above values are all hexadecimal numbers with the '0x' prefix.
> > +
>
> Superfluous newline.
Will remove
>
> > +Users: Kexec
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 3e8b760..8289e0c 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -76,6 +76,9 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> > {NULL_GUID, NULL, NULL},
> > };
> >
> > +void *efi_runtime_map;
> > +int nr_efi_runtime_map;
> > +
> > /*
> > * Returns 1 if 'facility' is enabled, 0 otherwise.
> > */
> > @@ -810,6 +813,19 @@ static void __init efi_merge_regions(void)
> > }
> > }
> >
> > +static int __init save_runtime_map(efi_memory_desc_t *md, int idx)
> > +{
> > + void *p;
> > + p = krealloc(efi_runtime_map, (idx + 1) * memmap.desc_size, GFP_KERNEL);
> > + if (!p)
> > + return -ENOMEM;
> > +
> > + efi_runtime_map = p;
> > + memcpy(efi_runtime_map + idx * memmap.desc_size, md, memmap.desc_size);
> > +
> > + return 0;
> > +}
> > +
> > /*
> > * Map efi memory ranges for runtime serivce and update new_memmap with virtual
> > * addresses.
> > @@ -820,6 +836,7 @@ static void * __init efi_map_regions(int *count)
> > void *p, *tmp, *new_memmap = NULL;
> > unsigned long size;
> > u64 end, systab;
> > + int err = 0;
> >
> > for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> > md = p;
> > @@ -848,10 +865,21 @@ static void * __init efi_map_regions(int *count)
> > new_memmap = tmp;
> > memcpy(new_memmap + (*count * memmap.desc_size), md,
> > memmap.desc_size);
> > + if (md->type != EFI_BOOT_SERVICES_CODE &&
> > + md->type != EFI_BOOT_SERVICES_DATA) {
> > + err = save_runtime_map(md, nr_efi_runtime_map);
> > + if (err)
> > + goto out_save_runtime;
> > + nr_efi_runtime_map++;
> > + }
>
> So why don't you move that code to save_runtime_map?
>
>
> It would looks like this:
>
> ...
> new_memmap = tmp;
> memcpy(new_memmap + (*count * memmap.desc_size), md,
> memmap.desc_size);
>
> save_runtime_map(md);
> (*count)++;
>
> [nr_efi_runtime_map is global, no need to pass it to save_runtime_map() ]
nr_efi_runtime_map is handled in diffrent way for 1st kernel and kexec kernel
For 1st kernel (boot from firmware) it's increased one by one in above function.
But for kexec kernel it is directly calculated from setup_data array len.
And increasing nr_efi_runtime_map in save_runtime_map is not ok the main reason
is I need the value firstly for the loop counter max value like below:
static int __init map_regions_fixed(void)
{
[snip]
for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
[snip]
save_runtime_map(md, i);
[snip]
}
>
> and the EFI_BOOT* tests can be done in save_runtime_map and also the
> error handling can happen there. This way efi_map_regions() won't
> need to know about anything. This way, you can later move the whole
> save_runtime_map() function to efi-kexec.c just by taking it without any
> need for untangling.
>
> > +out_save_runtime:
> > + kfree(efi_runtime_map);
> > + nr_efi_runtime_map = 0;
> > + efi_runtime_map = NULL;
>
> This can go there too.
This section can go the save_runtime_map but it looks clearer to put them here.
>
> > out_krealloc:
> > kfree(new_memmap);
> > return NULL;
> > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> > index 3150aa4..3d8d6f6 100644
> > --- a/drivers/firmware/efi/Kconfig
> > +++ b/drivers/firmware/efi/Kconfig
> > @@ -39,4 +39,15 @@ config EFI_VARS_PSTORE_DEFAULT_DISABLE
> > config UEFI_CPER
> > def_bool n
> >
> > +config EFI_RUNTIME_MAP
> > + bool "Export efi runtime maps to sysfs" if EXPERT
>
> What's with the EXPERT? It depends on KEXEC already.
EXPERT can be removed safely, will do.
>
> > + depends on X86 && EFI && KEXEC
> > + default y
> > + help
> > + Export efi runtime memory maps to /sys/firmware/efi/runtime-map.
> > + That memory map is used for example by kexec to set up efi virtual
> > + mapping the 2nd kernel, but can also be used for debugging purposes.
> > +
> > + See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map.
> > +
> > endmenu
>
> ...
>
> > +static int __init efi_runtime_map_init(void)
> > +{
> > + int i, j, ret = 0;
> > + struct efi_runtime_map_entry *entry;
> > +
> > + if (!efi_kobj)
> > + return 0;
> > +
> > + if (!efi_runtime_map)
> > + return 0;
> > +
> > + map_entries = kzalloc(nr_efi_runtime_map * sizeof(entry), GFP_KERNEL);
> > + if (!map_entries) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > +
> > + for (i = 0; i < nr_efi_runtime_map; i++) {
> > + entry = add_sysfs_runtime_map_entry(i);
> > + if (IS_ERR(entry)) {
> > + ret = PTR_ERR(entry);
> > + goto out_add_entry;
> > + }
> > + *(map_entries + i) = entry;
> > + }
> > +
> > + return 0;
> > +out_add_entry:
> > + for (j = i - 1; j > 0; j--) {
> > + entry = *(map_entries + j);
> > + kobject_put(&entry->kobj);
> > + }
> > + if (map_kset)
> > + kset_unregister(map_kset);
> > +out:
> > + return ret;
> > +}
> > +
> > +subsys_initcall(efi_runtime_map_init);
>
> Let me repeat myself:
>
> Why an initcall? Can't we run this from efisubsys_init()?
Sorry that I forgot to explain this in changelog, should ask you before.
I did try moving it to efisubsys_init but it need add extern declaration
for efi_runtime_map_init. Since link order will ensure it being called after
efisubsys_init I think it's fine with this static function.
--
Thanks for review
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-12 7:13 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 7:13 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
>
> >
> > and the EFI_BOOT* tests can be done in save_runtime_map and also the
> > error handling can happen there. This way efi_map_regions() won't
> > need to know about anything. This way, you can later move the whole
> > save_runtime_map() function to efi-kexec.c just by taking it without any
> > need for untangling.
> >
> > > +out_save_runtime:
> > > + kfree(efi_runtime_map);
> > > + nr_efi_runtime_map = 0;
> > > + efi_runtime_map = NULL;
> >
> > This can go there too.
>
> This section can go the save_runtime_map but it looks clearer to put them here.
BTW, I will restructure the whole code when I move them to efi_kexec.c,
so no worry about it? If you have strong opinion I can move them though.
Thanks
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-12 7:13 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 7:13 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
>
> >
> > and the EFI_BOOT* tests can be done in save_runtime_map and also the
> > error handling can happen there. This way efi_map_regions() won't
> > need to know about anything. This way, you can later move the whole
> > save_runtime_map() function to efi-kexec.c just by taking it without any
> > need for untangling.
> >
> > > +out_save_runtime:
> > > + kfree(efi_runtime_map);
> > > + nr_efi_runtime_map = 0;
> > > + efi_runtime_map = NULL;
> >
> > This can go there too.
>
> This section can go the save_runtime_map but it looks clearer to put them here.
BTW, I will restructure the whole code when I move them to efi_kexec.c,
so no worry about it? If you have strong opinion I can move them though.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-12 7:13 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 7:13 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
hpa-YMNOUZJC4hwAvxtiuMwx3w, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
>
> >
> > and the EFI_BOOT* tests can be done in save_runtime_map and also the
> > error handling can happen there. This way efi_map_regions() won't
> > need to know about anything. This way, you can later move the whole
> > save_runtime_map() function to efi-kexec.c just by taking it without any
> > need for untangling.
> >
> > > +out_save_runtime:
> > > + kfree(efi_runtime_map);
> > > + nr_efi_runtime_map = 0;
> > > + efi_runtime_map = NULL;
> >
> > This can go there too.
>
> This section can go the save_runtime_map but it looks clearer to put them here.
BTW, I will restructure the whole code when I move them to efi_kexec.c,
so no worry about it? If you have strong opinion I can move them though.
Thanks
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
2013-12-12 7:13 ` Dave Young
@ 2013-12-12 20:36 ` Borislav Petkov
-1 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-12 20:36 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On Thu, Dec 12, 2013 at 03:13:37PM +0800, Dave Young wrote:
> BTW, I will restructure the whole code when I move them to
> efi_kexec.c, so no worry about it? If you have strong opinion I can
> move them though.
Well, if it were me, I'd do it now so that it'll see more testing.
Later, it will be only a mechanical move of those functions which belong
to efi_kexec.c and won't need a second testing.
:-)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-12 20:36 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-12 20:36 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On Thu, Dec 12, 2013 at 03:13:37PM +0800, Dave Young wrote:
> BTW, I will restructure the whole code when I move them to
> efi_kexec.c, so no worry about it? If you have strong opinion I can
> move them though.
Well, if it were me, I'd do it now so that it'll see more testing.
Later, it will be only a mechanical move of those functions which belong
to efi_kexec.c and won't need a second testing.
:-)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-13 7:20 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-13 7:20 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On 12/12/13 at 09:36pm, Borislav Petkov wrote:
> On Thu, Dec 12, 2013 at 03:13:37PM +0800, Dave Young wrote:
> > BTW, I will restructure the whole code when I move them to
> > efi_kexec.c, so no worry about it? If you have strong opinion I can
> > move them though.
>
> Well, if it were me, I'd do it now so that it'll see more testing.
> Later, it will be only a mechanical move of those functions which belong
> to efi_kexec.c and won't need a second testing.
Will do, thanks.
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-13 7:20 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-13 7:20 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On 12/12/13 at 09:36pm, Borislav Petkov wrote:
> On Thu, Dec 12, 2013 at 03:13:37PM +0800, Dave Young wrote:
> > BTW, I will restructure the whole code when I move them to
> > efi_kexec.c, so no worry about it? If you have strong opinion I can
> > move them though.
>
> Well, if it were me, I'd do it now so that it'll see more testing.
> Later, it will be only a mechanical move of those functions which belong
> to efi_kexec.c and won't need a second testing.
Will do, thanks.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-13 7:20 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-13 7:20 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
hpa-YMNOUZJC4hwAvxtiuMwx3w, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On 12/12/13 at 09:36pm, Borislav Petkov wrote:
> On Thu, Dec 12, 2013 at 03:13:37PM +0800, Dave Young wrote:
> > BTW, I will restructure the whole code when I move them to
> > efi_kexec.c, so no worry about it? If you have strong opinion I can
> > move them though.
>
> Well, if it were me, I'd do it now so that it'll see more testing.
> Later, it will be only a mechanical move of those functions which belong
> to efi_kexec.c and won't need a second testing.
Will do, thanks.
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-12 20:53 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-12 20:53 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> Sorry that I forgot to explain this in changelog, should ask you before.
>
> I did try moving it to efisubsys_init but it need add extern declaration
So what? Add it.
> for efi_runtime_map_init. Since link order will ensure it being called after
> efisubsys_init I think it's fine with this static function.
This is actually exactly the reason why it shouldn't be another
subsys_initcall() if it can be helped. People would need to go have a
look at drivers/firmware/efi/Makefile to realize that the link order is
ok.
And, this is prone to future breakage if people go and move code around
and thereby change the link order.
Please call efi_runtime_map_init from efisubsys_init.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-12 20:53 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-12 20:53 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> Sorry that I forgot to explain this in changelog, should ask you before.
>
> I did try moving it to efisubsys_init but it need add extern declaration
So what? Add it.
> for efi_runtime_map_init. Since link order will ensure it being called after
> efisubsys_init I think it's fine with this static function.
This is actually exactly the reason why it shouldn't be another
subsys_initcall() if it can be helped. People would need to go have a
look at drivers/firmware/efi/Makefile to realize that the link order is
ok.
And, this is prone to future breakage if people go and move code around
and thereby change the link order.
Please call efi_runtime_map_init from efisubsys_init.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-12 20:53 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-12 20:53 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> Sorry that I forgot to explain this in changelog, should ask you before.
>
> I did try moving it to efisubsys_init but it need add extern declaration
So what? Add it.
> for efi_runtime_map_init. Since link order will ensure it being called after
> efisubsys_init I think it's fine with this static function.
This is actually exactly the reason why it shouldn't be another
subsys_initcall() if it can be helped. People would need to go have a
look at drivers/firmware/efi/Makefile to realize that the link order is
ok.
And, this is prone to future breakage if people go and move code around
and thereby change the link order.
Please call efi_runtime_map_init from efisubsys_init.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-13 7:26 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-13 7:26 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > Sorry that I forgot to explain this in changelog, should ask you before.
> >
> > I did try moving it to efisubsys_init but it need add extern declaration
>
> So what? Add it.
>
> > for efi_runtime_map_init. Since link order will ensure it being called after
> > efisubsys_init I think it's fine with this static function.
>
> This is actually exactly the reason why it shouldn't be another
> subsys_initcall() if it can be helped. People would need to go have a
> look at drivers/firmware/efi/Makefile to realize that the link order is
> ok.
>
> And, this is prone to future breakage if people go and move code around
> and thereby change the link order.
>
> Please call efi_runtime_map_init from efisubsys_init.
After moving to efisubsys_init, the code will looks like below, because
the funtion only is used in drivers/firmware/efi/efi.c thus I can not
add a blank function in #else section in the efi.h header file. Creating
another header file for this one function looks bad to me.
Is below changes fine to you? I can add it to next version if you like it.
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 9fbaeb2..2db7ea5 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -133,6 +133,10 @@ extern void efi_sync_low_kernel_mappings(void);
extern void efi_setup_page_tables(void);
extern void __init old_map_region(efi_memory_desc_t *md);
+#ifdef CONFIG_EFI_RUNTIME_MAP
+extern int __init efi_runtime_map_init(void);
+#endif
+
#ifdef CONFIG_EFI
static inline bool efi_is_native(void)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index afd0b49..85fd904 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -168,6 +168,12 @@ static int __init efisubsys_init(void)
goto err_unregister;
}
+#ifdef CONFIG_EFI_RUNTIME_MAP
+ error = efi_runtime_map_init();
+ if (error)
+ goto err_remove_group;
+#endif
+
/* and the standard mountpoint for efivarfs */
efivars_kobj = kobject_create_and_add("efivars", efi_kobj);
if (!efivars_kobj) {
diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
index e5e9984..5af06ad 100644
--- a/drivers/firmware/efi/runtime-map.c
+++ b/drivers/firmware/efi/runtime-map.c
@@ -135,7 +135,7 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
return entry;
}
-static int __init efi_runtime_map_init(void)
+int __init efi_runtime_map_init(void)
{
int i, j, ret = 0;
struct efi_runtime_map_entry *entry;
@@ -172,5 +172,3 @@ out_add_entry:
out:
return ret;
}
-
-subsys_initcall(efi_runtime_map_init);
--
Thanks
Dave
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-13 7:26 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-13 7:26 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > Sorry that I forgot to explain this in changelog, should ask you before.
> >
> > I did try moving it to efisubsys_init but it need add extern declaration
>
> So what? Add it.
>
> > for efi_runtime_map_init. Since link order will ensure it being called after
> > efisubsys_init I think it's fine with this static function.
>
> This is actually exactly the reason why it shouldn't be another
> subsys_initcall() if it can be helped. People would need to go have a
> look at drivers/firmware/efi/Makefile to realize that the link order is
> ok.
>
> And, this is prone to future breakage if people go and move code around
> and thereby change the link order.
>
> Please call efi_runtime_map_init from efisubsys_init.
After moving to efisubsys_init, the code will looks like below, because
the funtion only is used in drivers/firmware/efi/efi.c thus I can not
add a blank function in #else section in the efi.h header file. Creating
another header file for this one function looks bad to me.
Is below changes fine to you? I can add it to next version if you like it.
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 9fbaeb2..2db7ea5 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -133,6 +133,10 @@ extern void efi_sync_low_kernel_mappings(void);
extern void efi_setup_page_tables(void);
extern void __init old_map_region(efi_memory_desc_t *md);
+#ifdef CONFIG_EFI_RUNTIME_MAP
+extern int __init efi_runtime_map_init(void);
+#endif
+
#ifdef CONFIG_EFI
static inline bool efi_is_native(void)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index afd0b49..85fd904 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -168,6 +168,12 @@ static int __init efisubsys_init(void)
goto err_unregister;
}
+#ifdef CONFIG_EFI_RUNTIME_MAP
+ error = efi_runtime_map_init();
+ if (error)
+ goto err_remove_group;
+#endif
+
/* and the standard mountpoint for efivarfs */
efivars_kobj = kobject_create_and_add("efivars", efi_kobj);
if (!efivars_kobj) {
diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
index e5e9984..5af06ad 100644
--- a/drivers/firmware/efi/runtime-map.c
+++ b/drivers/firmware/efi/runtime-map.c
@@ -135,7 +135,7 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
return entry;
}
-static int __init efi_runtime_map_init(void)
+int __init efi_runtime_map_init(void)
{
int i, j, ret = 0;
struct efi_runtime_map_entry *entry;
@@ -172,5 +172,3 @@ out_add_entry:
out:
return ret;
}
-
-subsys_initcall(efi_runtime_map_init);
--
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-13 7:26 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-13 7:26 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
hpa-YMNOUZJC4hwAvxtiuMwx3w, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > Sorry that I forgot to explain this in changelog, should ask you before.
> >
> > I did try moving it to efisubsys_init but it need add extern declaration
>
> So what? Add it.
>
> > for efi_runtime_map_init. Since link order will ensure it being called after
> > efisubsys_init I think it's fine with this static function.
>
> This is actually exactly the reason why it shouldn't be another
> subsys_initcall() if it can be helped. People would need to go have a
> look at drivers/firmware/efi/Makefile to realize that the link order is
> ok.
>
> And, this is prone to future breakage if people go and move code around
> and thereby change the link order.
>
> Please call efi_runtime_map_init from efisubsys_init.
After moving to efisubsys_init, the code will looks like below, because
the funtion only is used in drivers/firmware/efi/efi.c thus I can not
add a blank function in #else section in the efi.h header file. Creating
another header file for this one function looks bad to me.
Is below changes fine to you? I can add it to next version if you like it.
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 9fbaeb2..2db7ea5 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -133,6 +133,10 @@ extern void efi_sync_low_kernel_mappings(void);
extern void efi_setup_page_tables(void);
extern void __init old_map_region(efi_memory_desc_t *md);
+#ifdef CONFIG_EFI_RUNTIME_MAP
+extern int __init efi_runtime_map_init(void);
+#endif
+
#ifdef CONFIG_EFI
static inline bool efi_is_native(void)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index afd0b49..85fd904 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -168,6 +168,12 @@ static int __init efisubsys_init(void)
goto err_unregister;
}
+#ifdef CONFIG_EFI_RUNTIME_MAP
+ error = efi_runtime_map_init();
+ if (error)
+ goto err_remove_group;
+#endif
+
/* and the standard mountpoint for efivarfs */
efivars_kobj = kobject_create_and_add("efivars", efi_kobj);
if (!efivars_kobj) {
diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
index e5e9984..5af06ad 100644
--- a/drivers/firmware/efi/runtime-map.c
+++ b/drivers/firmware/efi/runtime-map.c
@@ -135,7 +135,7 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
return entry;
}
-static int __init efi_runtime_map_init(void)
+int __init efi_runtime_map_init(void)
{
int i, j, ret = 0;
struct efi_runtime_map_entry *entry;
@@ -172,5 +172,3 @@ out_add_entry:
out:
return ret;
}
-
-subsys_initcall(efi_runtime_map_init);
--
Thanks
Dave
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-13 12:30 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-13 12:30 UTC (permalink / raw)
To: Dave Young
Cc: Borislav Petkov, linux-kernel, linux-efi, x86, mjg59, hpa,
James.Bottomley, vgoyal, ebiederm, horms, kexec, greg,
toshi.kani
On Fri, 13 Dec, at 03:26:00PM, Dave Young wrote:
> On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> > On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > > Sorry that I forgot to explain this in changelog, should ask you before.
> > >
> > > I did try moving it to efisubsys_init but it need add extern declaration
> >
> > So what? Add it.
> >
> > > for efi_runtime_map_init. Since link order will ensure it being called after
> > > efisubsys_init I think it's fine with this static function.
> >
> > This is actually exactly the reason why it shouldn't be another
> > subsys_initcall() if it can be helped. People would need to go have a
> > look at drivers/firmware/efi/Makefile to realize that the link order is
> > ok.
> >
> > And, this is prone to future breakage if people go and move code around
> > and thereby change the link order.
> >
> > Please call efi_runtime_map_init from efisubsys_init.
>
> After moving to efisubsys_init, the code will looks like below, because
> the funtion only is used in drivers/firmware/efi/efi.c thus I can not
> add a blank function in #else section in the efi.h header file. Creating
> another header file for this one function looks bad to me.
I agree with Borislav that this should be invoked from efisubsys_init().
Also Dave, there's nothing inherently x86-specific about runtime-map.c -
we've been trying not to dump arch-specific code in
drivers/firmware/efi/.
How about something like this, just to give you an idea? This would
allow the ARM/ia64 folks to enable this code if they want at some later
date. But more than that, it makes the code more self-contained and uses
some real interfaces instead of relying on global variables,
(not compile tested)
---
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 94a1cbcf6e2e..f45ea41deae0 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -76,8 +76,8 @@ static __initdata efi_config_table_type_t arch_tables[] = {
{NULL_GUID, NULL, NULL},
};
-void *efi_runtime_map;
-int nr_efi_runtime_map;
+static void *efi_runtime_map;
+static int nr_efi_runtime_map;
static u64 efi_setup; /* efi setup_data physical address */
/*
@@ -1084,6 +1084,9 @@ void __init efi_enter_virtual_mode(void)
}
}
+ efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_map,
+ boot_params.efi_info.efi_memdesc_size);
+
BUG_ON(!efi.systab);
efi_setup_page_tables();
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 0a288e306252..9870eb55d0e5 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -38,8 +38,7 @@ struct efi __read_mostly efi = {
};
EXPORT_SYMBOL(efi);
-struct kobject *efi_kobj;
-EXPORT_SYMBOL_GPL(efi_kobj);
+static struct kobject *efi_kobj;
static struct kobject *efivars_kobj;
/*
@@ -176,6 +175,8 @@ static int __init efisubsys_init(void)
goto err_remove_group;
}
+ efi_runtime_map_init(efi_kobj);
+
return 0;
err_remove_group:
diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
index e5e998494d8a..ef9631e9c03e 100644
--- a/drivers/firmware/efi/runtime-map.c
+++ b/drivers/firmware/efi/runtime-map.c
@@ -14,6 +14,10 @@
#include <asm/setup.h>
+static void *efi_runtime_map;
+static int nr_efi_runtime_map;
+static u32 efi_memdesc_size;
+
struct efi_runtime_map_entry {
efi_memory_desc_t md;
struct kobject kobj; /* kobject for each entry */
@@ -105,7 +109,6 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
{
int ret;
struct efi_runtime_map_entry *entry;
- struct efi_info *e = &boot_params.efi_info;
if (!map_kset) {
map_kset = kset_create_and_add("runtime-map", NULL,
@@ -120,7 +123,7 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
return entry;
}
- memcpy(&entry->md, efi_runtime_map + nr * e->efi_memdesc_size,
+ memcpy(&entry->md, efi_runtime_map + nr * efi_memdesc_size,
sizeof(efi_memory_desc_t));
kobject_init(&entry->kobj, &map_ktype);
@@ -135,7 +138,14 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
return entry;
}
-static int __init efi_runtime_map_init(void)
+int efi_runtime_map_setup(void *map, int nr_entries, u32 desc_size)
+{
+ efi_runtime_map = map;
+ nr_efi_runtime_map = nr_entries;
+ efi_memdesc_size = desc_size;
+}
+
+int __init efi_runtime_map_init(struct kobject *efi_kobj)
{
int i, j, ret = 0;
struct efi_runtime_map_entry *entry;
@@ -172,5 +182,3 @@ out_add_entry:
out:
return ret;
}
-
-subsys_initcall(efi_runtime_map_init);
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 4f1651d303b8..47e067044054 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -873,9 +873,8 @@ int efivars_sysfs_init(void);
#endif /* CONFIG_EFI_VARS */
#ifdef CONFIG_EFI_RUNTIME_MAP
-extern void *efi_runtime_map;
-extern int nr_efi_runtime_map;
-extern struct kobject *efi_kobj;
+int efi_runtime_map_init(struct kobject *);
+int efi_runtime_map_setup(void *, int, u32);
#endif
#endif /* _LINUX_EFI_H */
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-13 12:30 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-13 12:30 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, greg, x86, kexec, linux-kernel,
James.Bottomley, horms, Borislav Petkov, ebiederm, hpa, vgoyal
On Fri, 13 Dec, at 03:26:00PM, Dave Young wrote:
> On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> > On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > > Sorry that I forgot to explain this in changelog, should ask you before.
> > >
> > > I did try moving it to efisubsys_init but it need add extern declaration
> >
> > So what? Add it.
> >
> > > for efi_runtime_map_init. Since link order will ensure it being called after
> > > efisubsys_init I think it's fine with this static function.
> >
> > This is actually exactly the reason why it shouldn't be another
> > subsys_initcall() if it can be helped. People would need to go have a
> > look at drivers/firmware/efi/Makefile to realize that the link order is
> > ok.
> >
> > And, this is prone to future breakage if people go and move code around
> > and thereby change the link order.
> >
> > Please call efi_runtime_map_init from efisubsys_init.
>
> After moving to efisubsys_init, the code will looks like below, because
> the funtion only is used in drivers/firmware/efi/efi.c thus I can not
> add a blank function in #else section in the efi.h header file. Creating
> another header file for this one function looks bad to me.
I agree with Borislav that this should be invoked from efisubsys_init().
Also Dave, there's nothing inherently x86-specific about runtime-map.c -
we've been trying not to dump arch-specific code in
drivers/firmware/efi/.
How about something like this, just to give you an idea? This would
allow the ARM/ia64 folks to enable this code if they want at some later
date. But more than that, it makes the code more self-contained and uses
some real interfaces instead of relying on global variables,
(not compile tested)
---
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 94a1cbcf6e2e..f45ea41deae0 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -76,8 +76,8 @@ static __initdata efi_config_table_type_t arch_tables[] = {
{NULL_GUID, NULL, NULL},
};
-void *efi_runtime_map;
-int nr_efi_runtime_map;
+static void *efi_runtime_map;
+static int nr_efi_runtime_map;
static u64 efi_setup; /* efi setup_data physical address */
/*
@@ -1084,6 +1084,9 @@ void __init efi_enter_virtual_mode(void)
}
}
+ efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_map,
+ boot_params.efi_info.efi_memdesc_size);
+
BUG_ON(!efi.systab);
efi_setup_page_tables();
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 0a288e306252..9870eb55d0e5 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -38,8 +38,7 @@ struct efi __read_mostly efi = {
};
EXPORT_SYMBOL(efi);
-struct kobject *efi_kobj;
-EXPORT_SYMBOL_GPL(efi_kobj);
+static struct kobject *efi_kobj;
static struct kobject *efivars_kobj;
/*
@@ -176,6 +175,8 @@ static int __init efisubsys_init(void)
goto err_remove_group;
}
+ efi_runtime_map_init(efi_kobj);
+
return 0;
err_remove_group:
diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
index e5e998494d8a..ef9631e9c03e 100644
--- a/drivers/firmware/efi/runtime-map.c
+++ b/drivers/firmware/efi/runtime-map.c
@@ -14,6 +14,10 @@
#include <asm/setup.h>
+static void *efi_runtime_map;
+static int nr_efi_runtime_map;
+static u32 efi_memdesc_size;
+
struct efi_runtime_map_entry {
efi_memory_desc_t md;
struct kobject kobj; /* kobject for each entry */
@@ -105,7 +109,6 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
{
int ret;
struct efi_runtime_map_entry *entry;
- struct efi_info *e = &boot_params.efi_info;
if (!map_kset) {
map_kset = kset_create_and_add("runtime-map", NULL,
@@ -120,7 +123,7 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
return entry;
}
- memcpy(&entry->md, efi_runtime_map + nr * e->efi_memdesc_size,
+ memcpy(&entry->md, efi_runtime_map + nr * efi_memdesc_size,
sizeof(efi_memory_desc_t));
kobject_init(&entry->kobj, &map_ktype);
@@ -135,7 +138,14 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
return entry;
}
-static int __init efi_runtime_map_init(void)
+int efi_runtime_map_setup(void *map, int nr_entries, u32 desc_size)
+{
+ efi_runtime_map = map;
+ nr_efi_runtime_map = nr_entries;
+ efi_memdesc_size = desc_size;
+}
+
+int __init efi_runtime_map_init(struct kobject *efi_kobj)
{
int i, j, ret = 0;
struct efi_runtime_map_entry *entry;
@@ -172,5 +182,3 @@ out_add_entry:
out:
return ret;
}
-
-subsys_initcall(efi_runtime_map_init);
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 4f1651d303b8..47e067044054 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -873,9 +873,8 @@ int efivars_sysfs_init(void);
#endif /* CONFIG_EFI_VARS */
#ifdef CONFIG_EFI_RUNTIME_MAP
-extern void *efi_runtime_map;
-extern int nr_efi_runtime_map;
-extern struct kobject *efi_kobj;
+int efi_runtime_map_init(struct kobject *);
+int efi_runtime_map_setup(void *, int, u32);
#endif
#endif /* _LINUX_EFI_H */
--
Matt Fleming, Intel Open Source Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-13 12:30 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-13 12:30 UTC (permalink / raw)
To: Dave Young
Cc: Borislav Petkov, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w, toshi.kani-VXdhtT5mjnY
On Fri, 13 Dec, at 03:26:00PM, Dave Young wrote:
> On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> > On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > > Sorry that I forgot to explain this in changelog, should ask you before.
> > >
> > > I did try moving it to efisubsys_init but it need add extern declaration
> >
> > So what? Add it.
> >
> > > for efi_runtime_map_init. Since link order will ensure it being called after
> > > efisubsys_init I think it's fine with this static function.
> >
> > This is actually exactly the reason why it shouldn't be another
> > subsys_initcall() if it can be helped. People would need to go have a
> > look at drivers/firmware/efi/Makefile to realize that the link order is
> > ok.
> >
> > And, this is prone to future breakage if people go and move code around
> > and thereby change the link order.
> >
> > Please call efi_runtime_map_init from efisubsys_init.
>
> After moving to efisubsys_init, the code will looks like below, because
> the funtion only is used in drivers/firmware/efi/efi.c thus I can not
> add a blank function in #else section in the efi.h header file. Creating
> another header file for this one function looks bad to me.
I agree with Borislav that this should be invoked from efisubsys_init().
Also Dave, there's nothing inherently x86-specific about runtime-map.c -
we've been trying not to dump arch-specific code in
drivers/firmware/efi/.
How about something like this, just to give you an idea? This would
allow the ARM/ia64 folks to enable this code if they want at some later
date. But more than that, it makes the code more self-contained and uses
some real interfaces instead of relying on global variables,
(not compile tested)
---
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 94a1cbcf6e2e..f45ea41deae0 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -76,8 +76,8 @@ static __initdata efi_config_table_type_t arch_tables[] = {
{NULL_GUID, NULL, NULL},
};
-void *efi_runtime_map;
-int nr_efi_runtime_map;
+static void *efi_runtime_map;
+static int nr_efi_runtime_map;
static u64 efi_setup; /* efi setup_data physical address */
/*
@@ -1084,6 +1084,9 @@ void __init efi_enter_virtual_mode(void)
}
}
+ efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_map,
+ boot_params.efi_info.efi_memdesc_size);
+
BUG_ON(!efi.systab);
efi_setup_page_tables();
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 0a288e306252..9870eb55d0e5 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -38,8 +38,7 @@ struct efi __read_mostly efi = {
};
EXPORT_SYMBOL(efi);
-struct kobject *efi_kobj;
-EXPORT_SYMBOL_GPL(efi_kobj);
+static struct kobject *efi_kobj;
static struct kobject *efivars_kobj;
/*
@@ -176,6 +175,8 @@ static int __init efisubsys_init(void)
goto err_remove_group;
}
+ efi_runtime_map_init(efi_kobj);
+
return 0;
err_remove_group:
diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
index e5e998494d8a..ef9631e9c03e 100644
--- a/drivers/firmware/efi/runtime-map.c
+++ b/drivers/firmware/efi/runtime-map.c
@@ -14,6 +14,10 @@
#include <asm/setup.h>
+static void *efi_runtime_map;
+static int nr_efi_runtime_map;
+static u32 efi_memdesc_size;
+
struct efi_runtime_map_entry {
efi_memory_desc_t md;
struct kobject kobj; /* kobject for each entry */
@@ -105,7 +109,6 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
{
int ret;
struct efi_runtime_map_entry *entry;
- struct efi_info *e = &boot_params.efi_info;
if (!map_kset) {
map_kset = kset_create_and_add("runtime-map", NULL,
@@ -120,7 +123,7 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
return entry;
}
- memcpy(&entry->md, efi_runtime_map + nr * e->efi_memdesc_size,
+ memcpy(&entry->md, efi_runtime_map + nr * efi_memdesc_size,
sizeof(efi_memory_desc_t));
kobject_init(&entry->kobj, &map_ktype);
@@ -135,7 +138,14 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
return entry;
}
-static int __init efi_runtime_map_init(void)
+int efi_runtime_map_setup(void *map, int nr_entries, u32 desc_size)
+{
+ efi_runtime_map = map;
+ nr_efi_runtime_map = nr_entries;
+ efi_memdesc_size = desc_size;
+}
+
+int __init efi_runtime_map_init(struct kobject *efi_kobj)
{
int i, j, ret = 0;
struct efi_runtime_map_entry *entry;
@@ -172,5 +182,3 @@ out_add_entry:
out:
return ret;
}
-
-subsys_initcall(efi_runtime_map_init);
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 4f1651d303b8..47e067044054 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -873,9 +873,8 @@ int efivars_sysfs_init(void);
#endif /* CONFIG_EFI_VARS */
#ifdef CONFIG_EFI_RUNTIME_MAP
-extern void *efi_runtime_map;
-extern int nr_efi_runtime_map;
-extern struct kobject *efi_kobj;
+int efi_runtime_map_init(struct kobject *);
+int efi_runtime_map_setup(void *, int, u32);
#endif
#endif /* _LINUX_EFI_H */
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-16 1:33 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 1:33 UTC (permalink / raw)
To: Matt Fleming
Cc: Borislav Petkov, linux-kernel, linux-efi, x86, mjg59, hpa,
James.Bottomley, vgoyal, ebiederm, horms, kexec, greg,
toshi.kani
On 12/13/13 at 12:30pm, Matt Fleming wrote:
> On Fri, 13 Dec, at 03:26:00PM, Dave Young wrote:
> > On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> > > On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > > > Sorry that I forgot to explain this in changelog, should ask you before.
> > > >
> > > > I did try moving it to efisubsys_init but it need add extern declaration
> > >
> > > So what? Add it.
> > >
> > > > for efi_runtime_map_init. Since link order will ensure it being called after
> > > > efisubsys_init I think it's fine with this static function.
> > >
> > > This is actually exactly the reason why it shouldn't be another
> > > subsys_initcall() if it can be helped. People would need to go have a
> > > look at drivers/firmware/efi/Makefile to realize that the link order is
> > > ok.
> > >
> > > And, this is prone to future breakage if people go and move code around
> > > and thereby change the link order.
> > >
> > > Please call efi_runtime_map_init from efisubsys_init.
> >
> > After moving to efisubsys_init, the code will looks like below, because
Will call it in efi_subsys_init as what I replied previously.
> > the funtion only is used in drivers/firmware/efi/efi.c thus I can not
> > add a blank function in #else section in the efi.h header file. Creating
> > another header file for this one function looks bad to me.
>
> I agree with Borislav that this should be invoked from efisubsys_init().
> Also Dave, there's nothing inherently x86-specific about runtime-map.c -
> we've been trying not to dump arch-specific code in
> drivers/firmware/efi/.
>
> How about something like this, just to give you an idea? This would
> allow the ARM/ia64 folks to enable this code if they want at some later
> date. But more than that, it makes the code more self-contained and uses
> some real interfaces instead of relying on global variables,
>
> (not compile tested)
Thanks for the good idea, will tune and test the code.
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 94a1cbcf6e2e..f45ea41deae0 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -76,8 +76,8 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> {NULL_GUID, NULL, NULL},
> };
>
> -void *efi_runtime_map;
> -int nr_efi_runtime_map;
> +static void *efi_runtime_map;
> +static int nr_efi_runtime_map;
> static u64 efi_setup; /* efi setup_data physical address */
>
> /*
> @@ -1084,6 +1084,9 @@ void __init efi_enter_virtual_mode(void)
> }
> }
>
> + efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_map,
> + boot_params.efi_info.efi_memdesc_size);
> +
> BUG_ON(!efi.systab);
>
> efi_setup_page_tables();
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 0a288e306252..9870eb55d0e5 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -38,8 +38,7 @@ struct efi __read_mostly efi = {
> };
> EXPORT_SYMBOL(efi);
>
> -struct kobject *efi_kobj;
> -EXPORT_SYMBOL_GPL(efi_kobj);
> +static struct kobject *efi_kobj;
> static struct kobject *efivars_kobj;
>
> /*
> @@ -176,6 +175,8 @@ static int __init efisubsys_init(void)
> goto err_remove_group;
> }
>
> + efi_runtime_map_init(efi_kobj);
> +
> return 0;
>
> err_remove_group:
> diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
> index e5e998494d8a..ef9631e9c03e 100644
> --- a/drivers/firmware/efi/runtime-map.c
> +++ b/drivers/firmware/efi/runtime-map.c
> @@ -14,6 +14,10 @@
>
> #include <asm/setup.h>
>
> +static void *efi_runtime_map;
> +static int nr_efi_runtime_map;
> +static u32 efi_memdesc_size;
> +
> struct efi_runtime_map_entry {
> efi_memory_desc_t md;
> struct kobject kobj; /* kobject for each entry */
> @@ -105,7 +109,6 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> {
> int ret;
> struct efi_runtime_map_entry *entry;
> - struct efi_info *e = &boot_params.efi_info;
>
> if (!map_kset) {
> map_kset = kset_create_and_add("runtime-map", NULL,
> @@ -120,7 +123,7 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> return entry;
> }
>
> - memcpy(&entry->md, efi_runtime_map + nr * e->efi_memdesc_size,
> + memcpy(&entry->md, efi_runtime_map + nr * efi_memdesc_size,
> sizeof(efi_memory_desc_t));
>
> kobject_init(&entry->kobj, &map_ktype);
> @@ -135,7 +138,14 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> return entry;
> }
>
> -static int __init efi_runtime_map_init(void)
> +int efi_runtime_map_setup(void *map, int nr_entries, u32 desc_size)
> +{
> + efi_runtime_map = map;
> + nr_efi_runtime_map = nr_entries;
> + efi_memdesc_size = desc_size;
> +}
> +
> +int __init efi_runtime_map_init(struct kobject *efi_kobj)
> {
> int i, j, ret = 0;
> struct efi_runtime_map_entry *entry;
> @@ -172,5 +182,3 @@ out_add_entry:
> out:
> return ret;
> }
> -
> -subsys_initcall(efi_runtime_map_init);
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 4f1651d303b8..47e067044054 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -873,9 +873,8 @@ int efivars_sysfs_init(void);
> #endif /* CONFIG_EFI_VARS */
>
> #ifdef CONFIG_EFI_RUNTIME_MAP
> -extern void *efi_runtime_map;
> -extern int nr_efi_runtime_map;
> -extern struct kobject *efi_kobj;
> +int efi_runtime_map_init(struct kobject *);
> +int efi_runtime_map_setup(void *, int, u32);
> #endif
>
> #endif /* _LINUX_EFI_H */
>
> --
> Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-16 1:33 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 1:33 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59, linux-efi, toshi.kani, greg, x86, kexec, linux-kernel,
James.Bottomley, horms, Borislav Petkov, ebiederm, hpa, vgoyal
On 12/13/13 at 12:30pm, Matt Fleming wrote:
> On Fri, 13 Dec, at 03:26:00PM, Dave Young wrote:
> > On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> > > On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > > > Sorry that I forgot to explain this in changelog, should ask you before.
> > > >
> > > > I did try moving it to efisubsys_init but it need add extern declaration
> > >
> > > So what? Add it.
> > >
> > > > for efi_runtime_map_init. Since link order will ensure it being called after
> > > > efisubsys_init I think it's fine with this static function.
> > >
> > > This is actually exactly the reason why it shouldn't be another
> > > subsys_initcall() if it can be helped. People would need to go have a
> > > look at drivers/firmware/efi/Makefile to realize that the link order is
> > > ok.
> > >
> > > And, this is prone to future breakage if people go and move code around
> > > and thereby change the link order.
> > >
> > > Please call efi_runtime_map_init from efisubsys_init.
> >
> > After moving to efisubsys_init, the code will looks like below, because
Will call it in efi_subsys_init as what I replied previously.
> > the funtion only is used in drivers/firmware/efi/efi.c thus I can not
> > add a blank function in #else section in the efi.h header file. Creating
> > another header file for this one function looks bad to me.
>
> I agree with Borislav that this should be invoked from efisubsys_init().
> Also Dave, there's nothing inherently x86-specific about runtime-map.c -
> we've been trying not to dump arch-specific code in
> drivers/firmware/efi/.
>
> How about something like this, just to give you an idea? This would
> allow the ARM/ia64 folks to enable this code if they want at some later
> date. But more than that, it makes the code more self-contained and uses
> some real interfaces instead of relying on global variables,
>
> (not compile tested)
Thanks for the good idea, will tune and test the code.
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 94a1cbcf6e2e..f45ea41deae0 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -76,8 +76,8 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> {NULL_GUID, NULL, NULL},
> };
>
> -void *efi_runtime_map;
> -int nr_efi_runtime_map;
> +static void *efi_runtime_map;
> +static int nr_efi_runtime_map;
> static u64 efi_setup; /* efi setup_data physical address */
>
> /*
> @@ -1084,6 +1084,9 @@ void __init efi_enter_virtual_mode(void)
> }
> }
>
> + efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_map,
> + boot_params.efi_info.efi_memdesc_size);
> +
> BUG_ON(!efi.systab);
>
> efi_setup_page_tables();
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 0a288e306252..9870eb55d0e5 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -38,8 +38,7 @@ struct efi __read_mostly efi = {
> };
> EXPORT_SYMBOL(efi);
>
> -struct kobject *efi_kobj;
> -EXPORT_SYMBOL_GPL(efi_kobj);
> +static struct kobject *efi_kobj;
> static struct kobject *efivars_kobj;
>
> /*
> @@ -176,6 +175,8 @@ static int __init efisubsys_init(void)
> goto err_remove_group;
> }
>
> + efi_runtime_map_init(efi_kobj);
> +
> return 0;
>
> err_remove_group:
> diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
> index e5e998494d8a..ef9631e9c03e 100644
> --- a/drivers/firmware/efi/runtime-map.c
> +++ b/drivers/firmware/efi/runtime-map.c
> @@ -14,6 +14,10 @@
>
> #include <asm/setup.h>
>
> +static void *efi_runtime_map;
> +static int nr_efi_runtime_map;
> +static u32 efi_memdesc_size;
> +
> struct efi_runtime_map_entry {
> efi_memory_desc_t md;
> struct kobject kobj; /* kobject for each entry */
> @@ -105,7 +109,6 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> {
> int ret;
> struct efi_runtime_map_entry *entry;
> - struct efi_info *e = &boot_params.efi_info;
>
> if (!map_kset) {
> map_kset = kset_create_and_add("runtime-map", NULL,
> @@ -120,7 +123,7 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> return entry;
> }
>
> - memcpy(&entry->md, efi_runtime_map + nr * e->efi_memdesc_size,
> + memcpy(&entry->md, efi_runtime_map + nr * efi_memdesc_size,
> sizeof(efi_memory_desc_t));
>
> kobject_init(&entry->kobj, &map_ktype);
> @@ -135,7 +138,14 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> return entry;
> }
>
> -static int __init efi_runtime_map_init(void)
> +int efi_runtime_map_setup(void *map, int nr_entries, u32 desc_size)
> +{
> + efi_runtime_map = map;
> + nr_efi_runtime_map = nr_entries;
> + efi_memdesc_size = desc_size;
> +}
> +
> +int __init efi_runtime_map_init(struct kobject *efi_kobj)
> {
> int i, j, ret = 0;
> struct efi_runtime_map_entry *entry;
> @@ -172,5 +182,3 @@ out_add_entry:
> out:
> return ret;
> }
> -
> -subsys_initcall(efi_runtime_map_init);
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 4f1651d303b8..47e067044054 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -873,9 +873,8 @@ int efivars_sysfs_init(void);
> #endif /* CONFIG_EFI_VARS */
>
> #ifdef CONFIG_EFI_RUNTIME_MAP
> -extern void *efi_runtime_map;
> -extern int nr_efi_runtime_map;
> -extern struct kobject *efi_kobj;
> +int efi_runtime_map_init(struct kobject *);
> +int efi_runtime_map_setup(void *, int, u32);
> #endif
>
> #endif /* _LINUX_EFI_H */
>
> --
> Matt Fleming, Intel Open Source Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-16 1:33 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 1:33 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, greg-U8xfFu+wG4EAvxtiuMwx3w,
x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, Borislav Petkov,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On 12/13/13 at 12:30pm, Matt Fleming wrote:
> On Fri, 13 Dec, at 03:26:00PM, Dave Young wrote:
> > On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> > > On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > > > Sorry that I forgot to explain this in changelog, should ask you before.
> > > >
> > > > I did try moving it to efisubsys_init but it need add extern declaration
> > >
> > > So what? Add it.
> > >
> > > > for efi_runtime_map_init. Since link order will ensure it being called after
> > > > efisubsys_init I think it's fine with this static function.
> > >
> > > This is actually exactly the reason why it shouldn't be another
> > > subsys_initcall() if it can be helped. People would need to go have a
> > > look at drivers/firmware/efi/Makefile to realize that the link order is
> > > ok.
> > >
> > > And, this is prone to future breakage if people go and move code around
> > > and thereby change the link order.
> > >
> > > Please call efi_runtime_map_init from efisubsys_init.
> >
> > After moving to efisubsys_init, the code will looks like below, because
Will call it in efi_subsys_init as what I replied previously.
> > the funtion only is used in drivers/firmware/efi/efi.c thus I can not
> > add a blank function in #else section in the efi.h header file. Creating
> > another header file for this one function looks bad to me.
>
> I agree with Borislav that this should be invoked from efisubsys_init().
> Also Dave, there's nothing inherently x86-specific about runtime-map.c -
> we've been trying not to dump arch-specific code in
> drivers/firmware/efi/.
>
> How about something like this, just to give you an idea? This would
> allow the ARM/ia64 folks to enable this code if they want at some later
> date. But more than that, it makes the code more self-contained and uses
> some real interfaces instead of relying on global variables,
>
> (not compile tested)
Thanks for the good idea, will tune and test the code.
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 94a1cbcf6e2e..f45ea41deae0 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -76,8 +76,8 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> {NULL_GUID, NULL, NULL},
> };
>
> -void *efi_runtime_map;
> -int nr_efi_runtime_map;
> +static void *efi_runtime_map;
> +static int nr_efi_runtime_map;
> static u64 efi_setup; /* efi setup_data physical address */
>
> /*
> @@ -1084,6 +1084,9 @@ void __init efi_enter_virtual_mode(void)
> }
> }
>
> + efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_map,
> + boot_params.efi_info.efi_memdesc_size);
> +
> BUG_ON(!efi.systab);
>
> efi_setup_page_tables();
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 0a288e306252..9870eb55d0e5 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -38,8 +38,7 @@ struct efi __read_mostly efi = {
> };
> EXPORT_SYMBOL(efi);
>
> -struct kobject *efi_kobj;
> -EXPORT_SYMBOL_GPL(efi_kobj);
> +static struct kobject *efi_kobj;
> static struct kobject *efivars_kobj;
>
> /*
> @@ -176,6 +175,8 @@ static int __init efisubsys_init(void)
> goto err_remove_group;
> }
>
> + efi_runtime_map_init(efi_kobj);
> +
> return 0;
>
> err_remove_group:
> diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
> index e5e998494d8a..ef9631e9c03e 100644
> --- a/drivers/firmware/efi/runtime-map.c
> +++ b/drivers/firmware/efi/runtime-map.c
> @@ -14,6 +14,10 @@
>
> #include <asm/setup.h>
>
> +static void *efi_runtime_map;
> +static int nr_efi_runtime_map;
> +static u32 efi_memdesc_size;
> +
> struct efi_runtime_map_entry {
> efi_memory_desc_t md;
> struct kobject kobj; /* kobject for each entry */
> @@ -105,7 +109,6 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> {
> int ret;
> struct efi_runtime_map_entry *entry;
> - struct efi_info *e = &boot_params.efi_info;
>
> if (!map_kset) {
> map_kset = kset_create_and_add("runtime-map", NULL,
> @@ -120,7 +123,7 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> return entry;
> }
>
> - memcpy(&entry->md, efi_runtime_map + nr * e->efi_memdesc_size,
> + memcpy(&entry->md, efi_runtime_map + nr * efi_memdesc_size,
> sizeof(efi_memory_desc_t));
>
> kobject_init(&entry->kobj, &map_ktype);
> @@ -135,7 +138,14 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> return entry;
> }
>
> -static int __init efi_runtime_map_init(void)
> +int efi_runtime_map_setup(void *map, int nr_entries, u32 desc_size)
> +{
> + efi_runtime_map = map;
> + nr_efi_runtime_map = nr_entries;
> + efi_memdesc_size = desc_size;
> +}
> +
> +int __init efi_runtime_map_init(struct kobject *efi_kobj)
> {
> int i, j, ret = 0;
> struct efi_runtime_map_entry *entry;
> @@ -172,5 +182,3 @@ out_add_entry:
> out:
> return ret;
> }
> -
> -subsys_initcall(efi_runtime_map_init);
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 4f1651d303b8..47e067044054 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -873,9 +873,8 @@ int efivars_sysfs_init(void);
> #endif /* CONFIG_EFI_VARS */
>
> #ifdef CONFIG_EFI_RUNTIME_MAP
> -extern void *efi_runtime_map;
> -extern int nr_efi_runtime_map;
> -extern struct kobject *efi_kobj;
> +int efi_runtime_map_init(struct kobject *);
> +int efi_runtime_map_setup(void *, int, u32);
> #endif
>
> #endif /* _LINUX_EFI_H */
>
> --
> Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-16 3:02 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 3:02 UTC (permalink / raw)
To: Matt Fleming
Cc: Borislav Petkov, linux-kernel, linux-efi, x86, mjg59, hpa,
James.Bottomley, vgoyal, ebiederm, horms, kexec, greg,
toshi.kani
On 12/16/13 at 09:33am, Dave Young wrote:
> On 12/13/13 at 12:30pm, Matt Fleming wrote:
> > On Fri, 13 Dec, at 03:26:00PM, Dave Young wrote:
> > > On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> > > > On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > > > > Sorry that I forgot to explain this in changelog, should ask you before.
> > > > >
> > > > > I did try moving it to efisubsys_init but it need add extern declaration
> > > >
> > > > So what? Add it.
> > > >
> > > > > for efi_runtime_map_init. Since link order will ensure it being called after
> > > > > efisubsys_init I think it's fine with this static function.
> > > >
> > > > This is actually exactly the reason why it shouldn't be another
> > > > subsys_initcall() if it can be helped. People would need to go have a
> > > > look at drivers/firmware/efi/Makefile to realize that the link order is
> > > > ok.
> > > >
> > > > And, this is prone to future breakage if people go and move code around
> > > > and thereby change the link order.
> > > >
> > > > Please call efi_runtime_map_init from efisubsys_init.
> > >
> > > After moving to efisubsys_init, the code will looks like below, because
>
> Will call it in efi_subsys_init as what I replied previously.
Actually change a bit from your below suggestion.
>
> > > the funtion only is used in drivers/firmware/efi/efi.c thus I can not
> > > add a blank function in #else section in the efi.h header file. Creating
> > > another header file for this one function looks bad to me.
> >
> > I agree with Borislav that this should be invoked from efisubsys_init().
> > Also Dave, there's nothing inherently x86-specific about runtime-map.c -
> > we've been trying not to dump arch-specific code in
> > drivers/firmware/efi/.
> >
> > How about something like this, just to give you an idea? This would
> > allow the ARM/ia64 folks to enable this code if they want at some later
> > date. But more than that, it makes the code more self-contained and uses
> > some real interfaces instead of relying on global variables,
> >
> > (not compile tested)
>
> Thanks for the good idea, will tune and test the code.
>
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 94a1cbcf6e2e..f45ea41deae0 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -76,8 +76,8 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> > {NULL_GUID, NULL, NULL},
> > };
> >
> > -void *efi_runtime_map;
> > -int nr_efi_runtime_map;
> > +static void *efi_runtime_map;
> > +static int nr_efi_runtime_map;
> > static u64 efi_setup; /* efi setup_data physical address */
> >
> > /*
> > @@ -1084,6 +1084,9 @@ void __init efi_enter_virtual_mode(void)
> > }
> > }
> >
> > + efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_map,
> > + boot_params.efi_info.efi_memdesc_size);
> > +
> > BUG_ON(!efi.systab);
> >
> > efi_setup_page_tables();
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 0a288e306252..9870eb55d0e5 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -38,8 +38,7 @@ struct efi __read_mostly efi = {
> > };
> > EXPORT_SYMBOL(efi);
> >
> > -struct kobject *efi_kobj;
> > -EXPORT_SYMBOL_GPL(efi_kobj);
> > +static struct kobject *efi_kobj;
> > static struct kobject *efivars_kobj;
> >
> > /*
> > @@ -176,6 +175,8 @@ static int __init efisubsys_init(void)
> > goto err_remove_group;
> > }
> >
> > + efi_runtime_map_init(efi_kobj);
Will add #ifdef CONFIG_EFI_RUNTIME_MAP around above line and add
error handling
Also will update the usage of gloable efi_kobj, pass it via function
parameter.
> > +
> > return 0;
> >
> > err_remove_group:
> > diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
> > index e5e998494d8a..ef9631e9c03e 100644
> > --- a/drivers/firmware/efi/runtime-map.c
> > +++ b/drivers/firmware/efi/runtime-map.c
> > @@ -14,6 +14,10 @@
> >
> > #include <asm/setup.h>
> >
> > +static void *efi_runtime_map;
> > +static int nr_efi_runtime_map;
> > +static u32 efi_memdesc_size;
> > +
> > struct efi_runtime_map_entry {
> > efi_memory_desc_t md;
> > struct kobject kobj; /* kobject for each entry */
> > @@ -105,7 +109,6 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> > {
> > int ret;
> > struct efi_runtime_map_entry *entry;
> > - struct efi_info *e = &boot_params.efi_info;
> >
> > if (!map_kset) {
> > map_kset = kset_create_and_add("runtime-map", NULL,
> > @@ -120,7 +123,7 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> > return entry;
> > }
> >
> > - memcpy(&entry->md, efi_runtime_map + nr * e->efi_memdesc_size,
> > + memcpy(&entry->md, efi_runtime_map + nr * efi_memdesc_size,
> > sizeof(efi_memory_desc_t));
> >
> > kobject_init(&entry->kobj, &map_ktype);
> > @@ -135,7 +138,14 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> > return entry;
> > }
> >
> > -static int __init efi_runtime_map_init(void)
> > +int efi_runtime_map_setup(void *map, int nr_entries, u32 desc_size)
Will change it to void instead of return int
> > +{
> > + efi_runtime_map = map;
> > + nr_efi_runtime_map = nr_entries;
> > + efi_memdesc_size = desc_size;
> > +}
> > +
> > +int __init efi_runtime_map_init(struct kobject *efi_kobj)
> > {
> > int i, j, ret = 0;
> > struct efi_runtime_map_entry *entry;
> > @@ -172,5 +182,3 @@ out_add_entry:
> > out:
> > return ret;
> > }
> > -
> > -subsys_initcall(efi_runtime_map_init);
> > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > index 4f1651d303b8..47e067044054 100644
> > --- a/include/linux/efi.h
> > +++ b/include/linux/efi.h
> > @@ -873,9 +873,8 @@ int efivars_sysfs_init(void);
> > #endif /* CONFIG_EFI_VARS */
> >
> > #ifdef CONFIG_EFI_RUNTIME_MAP
> > -extern void *efi_runtime_map;
> > -extern int nr_efi_runtime_map;
> > -extern struct kobject *efi_kobj;
> > +int efi_runtime_map_init(struct kobject *);
> > +int efi_runtime_map_setup(void *, int, u32);
Will change to void.
> > #endif
> >
> > #endif /* _LINUX_EFI_H */
> >
> > --
> > Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-16 3:02 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 3:02 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59, linux-efi, toshi.kani, greg, x86, kexec, linux-kernel,
James.Bottomley, horms, Borislav Petkov, ebiederm, hpa, vgoyal
On 12/16/13 at 09:33am, Dave Young wrote:
> On 12/13/13 at 12:30pm, Matt Fleming wrote:
> > On Fri, 13 Dec, at 03:26:00PM, Dave Young wrote:
> > > On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> > > > On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > > > > Sorry that I forgot to explain this in changelog, should ask you before.
> > > > >
> > > > > I did try moving it to efisubsys_init but it need add extern declaration
> > > >
> > > > So what? Add it.
> > > >
> > > > > for efi_runtime_map_init. Since link order will ensure it being called after
> > > > > efisubsys_init I think it's fine with this static function.
> > > >
> > > > This is actually exactly the reason why it shouldn't be another
> > > > subsys_initcall() if it can be helped. People would need to go have a
> > > > look at drivers/firmware/efi/Makefile to realize that the link order is
> > > > ok.
> > > >
> > > > And, this is prone to future breakage if people go and move code around
> > > > and thereby change the link order.
> > > >
> > > > Please call efi_runtime_map_init from efisubsys_init.
> > >
> > > After moving to efisubsys_init, the code will looks like below, because
>
> Will call it in efi_subsys_init as what I replied previously.
Actually change a bit from your below suggestion.
>
> > > the funtion only is used in drivers/firmware/efi/efi.c thus I can not
> > > add a blank function in #else section in the efi.h header file. Creating
> > > another header file for this one function looks bad to me.
> >
> > I agree with Borislav that this should be invoked from efisubsys_init().
> > Also Dave, there's nothing inherently x86-specific about runtime-map.c -
> > we've been trying not to dump arch-specific code in
> > drivers/firmware/efi/.
> >
> > How about something like this, just to give you an idea? This would
> > allow the ARM/ia64 folks to enable this code if they want at some later
> > date. But more than that, it makes the code more self-contained and uses
> > some real interfaces instead of relying on global variables,
> >
> > (not compile tested)
>
> Thanks for the good idea, will tune and test the code.
>
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 94a1cbcf6e2e..f45ea41deae0 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -76,8 +76,8 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> > {NULL_GUID, NULL, NULL},
> > };
> >
> > -void *efi_runtime_map;
> > -int nr_efi_runtime_map;
> > +static void *efi_runtime_map;
> > +static int nr_efi_runtime_map;
> > static u64 efi_setup; /* efi setup_data physical address */
> >
> > /*
> > @@ -1084,6 +1084,9 @@ void __init efi_enter_virtual_mode(void)
> > }
> > }
> >
> > + efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_map,
> > + boot_params.efi_info.efi_memdesc_size);
> > +
> > BUG_ON(!efi.systab);
> >
> > efi_setup_page_tables();
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 0a288e306252..9870eb55d0e5 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -38,8 +38,7 @@ struct efi __read_mostly efi = {
> > };
> > EXPORT_SYMBOL(efi);
> >
> > -struct kobject *efi_kobj;
> > -EXPORT_SYMBOL_GPL(efi_kobj);
> > +static struct kobject *efi_kobj;
> > static struct kobject *efivars_kobj;
> >
> > /*
> > @@ -176,6 +175,8 @@ static int __init efisubsys_init(void)
> > goto err_remove_group;
> > }
> >
> > + efi_runtime_map_init(efi_kobj);
Will add #ifdef CONFIG_EFI_RUNTIME_MAP around above line and add
error handling
Also will update the usage of gloable efi_kobj, pass it via function
parameter.
> > +
> > return 0;
> >
> > err_remove_group:
> > diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
> > index e5e998494d8a..ef9631e9c03e 100644
> > --- a/drivers/firmware/efi/runtime-map.c
> > +++ b/drivers/firmware/efi/runtime-map.c
> > @@ -14,6 +14,10 @@
> >
> > #include <asm/setup.h>
> >
> > +static void *efi_runtime_map;
> > +static int nr_efi_runtime_map;
> > +static u32 efi_memdesc_size;
> > +
> > struct efi_runtime_map_entry {
> > efi_memory_desc_t md;
> > struct kobject kobj; /* kobject for each entry */
> > @@ -105,7 +109,6 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> > {
> > int ret;
> > struct efi_runtime_map_entry *entry;
> > - struct efi_info *e = &boot_params.efi_info;
> >
> > if (!map_kset) {
> > map_kset = kset_create_and_add("runtime-map", NULL,
> > @@ -120,7 +123,7 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> > return entry;
> > }
> >
> > - memcpy(&entry->md, efi_runtime_map + nr * e->efi_memdesc_size,
> > + memcpy(&entry->md, efi_runtime_map + nr * efi_memdesc_size,
> > sizeof(efi_memory_desc_t));
> >
> > kobject_init(&entry->kobj, &map_ktype);
> > @@ -135,7 +138,14 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> > return entry;
> > }
> >
> > -static int __init efi_runtime_map_init(void)
> > +int efi_runtime_map_setup(void *map, int nr_entries, u32 desc_size)
Will change it to void instead of return int
> > +{
> > + efi_runtime_map = map;
> > + nr_efi_runtime_map = nr_entries;
> > + efi_memdesc_size = desc_size;
> > +}
> > +
> > +int __init efi_runtime_map_init(struct kobject *efi_kobj)
> > {
> > int i, j, ret = 0;
> > struct efi_runtime_map_entry *entry;
> > @@ -172,5 +182,3 @@ out_add_entry:
> > out:
> > return ret;
> > }
> > -
> > -subsys_initcall(efi_runtime_map_init);
> > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > index 4f1651d303b8..47e067044054 100644
> > --- a/include/linux/efi.h
> > +++ b/include/linux/efi.h
> > @@ -873,9 +873,8 @@ int efivars_sysfs_init(void);
> > #endif /* CONFIG_EFI_VARS */
> >
> > #ifdef CONFIG_EFI_RUNTIME_MAP
> > -extern void *efi_runtime_map;
> > -extern int nr_efi_runtime_map;
> > -extern struct kobject *efi_kobj;
> > +int efi_runtime_map_init(struct kobject *);
> > +int efi_runtime_map_setup(void *, int, u32);
Will change to void.
> > #endif
> >
> > #endif /* _LINUX_EFI_H */
> >
> > --
> > Matt Fleming, Intel Open Source Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-16 3:02 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 3:02 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, greg-U8xfFu+wG4EAvxtiuMwx3w,
x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, Borislav Petkov,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On 12/16/13 at 09:33am, Dave Young wrote:
> On 12/13/13 at 12:30pm, Matt Fleming wrote:
> > On Fri, 13 Dec, at 03:26:00PM, Dave Young wrote:
> > > On 12/12/13 at 09:53pm, Borislav Petkov wrote:
> > > > On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> > > > > Sorry that I forgot to explain this in changelog, should ask you before.
> > > > >
> > > > > I did try moving it to efisubsys_init but it need add extern declaration
> > > >
> > > > So what? Add it.
> > > >
> > > > > for efi_runtime_map_init. Since link order will ensure it being called after
> > > > > efisubsys_init I think it's fine with this static function.
> > > >
> > > > This is actually exactly the reason why it shouldn't be another
> > > > subsys_initcall() if it can be helped. People would need to go have a
> > > > look at drivers/firmware/efi/Makefile to realize that the link order is
> > > > ok.
> > > >
> > > > And, this is prone to future breakage if people go and move code around
> > > > and thereby change the link order.
> > > >
> > > > Please call efi_runtime_map_init from efisubsys_init.
> > >
> > > After moving to efisubsys_init, the code will looks like below, because
>
> Will call it in efi_subsys_init as what I replied previously.
Actually change a bit from your below suggestion.
>
> > > the funtion only is used in drivers/firmware/efi/efi.c thus I can not
> > > add a blank function in #else section in the efi.h header file. Creating
> > > another header file for this one function looks bad to me.
> >
> > I agree with Borislav that this should be invoked from efisubsys_init().
> > Also Dave, there's nothing inherently x86-specific about runtime-map.c -
> > we've been trying not to dump arch-specific code in
> > drivers/firmware/efi/.
> >
> > How about something like this, just to give you an idea? This would
> > allow the ARM/ia64 folks to enable this code if they want at some later
> > date. But more than that, it makes the code more self-contained and uses
> > some real interfaces instead of relying on global variables,
> >
> > (not compile tested)
>
> Thanks for the good idea, will tune and test the code.
>
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 94a1cbcf6e2e..f45ea41deae0 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -76,8 +76,8 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> > {NULL_GUID, NULL, NULL},
> > };
> >
> > -void *efi_runtime_map;
> > -int nr_efi_runtime_map;
> > +static void *efi_runtime_map;
> > +static int nr_efi_runtime_map;
> > static u64 efi_setup; /* efi setup_data physical address */
> >
> > /*
> > @@ -1084,6 +1084,9 @@ void __init efi_enter_virtual_mode(void)
> > }
> > }
> >
> > + efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_map,
> > + boot_params.efi_info.efi_memdesc_size);
> > +
> > BUG_ON(!efi.systab);
> >
> > efi_setup_page_tables();
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 0a288e306252..9870eb55d0e5 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -38,8 +38,7 @@ struct efi __read_mostly efi = {
> > };
> > EXPORT_SYMBOL(efi);
> >
> > -struct kobject *efi_kobj;
> > -EXPORT_SYMBOL_GPL(efi_kobj);
> > +static struct kobject *efi_kobj;
> > static struct kobject *efivars_kobj;
> >
> > /*
> > @@ -176,6 +175,8 @@ static int __init efisubsys_init(void)
> > goto err_remove_group;
> > }
> >
> > + efi_runtime_map_init(efi_kobj);
Will add #ifdef CONFIG_EFI_RUNTIME_MAP around above line and add
error handling
Also will update the usage of gloable efi_kobj, pass it via function
parameter.
> > +
> > return 0;
> >
> > err_remove_group:
> > diff --git a/drivers/firmware/efi/runtime-map.c b/drivers/firmware/efi/runtime-map.c
> > index e5e998494d8a..ef9631e9c03e 100644
> > --- a/drivers/firmware/efi/runtime-map.c
> > +++ b/drivers/firmware/efi/runtime-map.c
> > @@ -14,6 +14,10 @@
> >
> > #include <asm/setup.h>
> >
> > +static void *efi_runtime_map;
> > +static int nr_efi_runtime_map;
> > +static u32 efi_memdesc_size;
> > +
> > struct efi_runtime_map_entry {
> > efi_memory_desc_t md;
> > struct kobject kobj; /* kobject for each entry */
> > @@ -105,7 +109,6 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> > {
> > int ret;
> > struct efi_runtime_map_entry *entry;
> > - struct efi_info *e = &boot_params.efi_info;
> >
> > if (!map_kset) {
> > map_kset = kset_create_and_add("runtime-map", NULL,
> > @@ -120,7 +123,7 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> > return entry;
> > }
> >
> > - memcpy(&entry->md, efi_runtime_map + nr * e->efi_memdesc_size,
> > + memcpy(&entry->md, efi_runtime_map + nr * efi_memdesc_size,
> > sizeof(efi_memory_desc_t));
> >
> > kobject_init(&entry->kobj, &map_ktype);
> > @@ -135,7 +138,14 @@ static struct efi_runtime_map_entry *add_sysfs_runtime_map_entry(int nr)
> > return entry;
> > }
> >
> > -static int __init efi_runtime_map_init(void)
> > +int efi_runtime_map_setup(void *map, int nr_entries, u32 desc_size)
Will change it to void instead of return int
> > +{
> > + efi_runtime_map = map;
> > + nr_efi_runtime_map = nr_entries;
> > + efi_memdesc_size = desc_size;
> > +}
> > +
> > +int __init efi_runtime_map_init(struct kobject *efi_kobj)
> > {
> > int i, j, ret = 0;
> > struct efi_runtime_map_entry *entry;
> > @@ -172,5 +182,3 @@ out_add_entry:
> > out:
> > return ret;
> > }
> > -
> > -subsys_initcall(efi_runtime_map_init);
> > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > index 4f1651d303b8..47e067044054 100644
> > --- a/include/linux/efi.h
> > +++ b/include/linux/efi.h
> > @@ -873,9 +873,8 @@ int efivars_sysfs_init(void);
> > #endif /* CONFIG_EFI_VARS */
> >
> > #ifdef CONFIG_EFI_RUNTIME_MAP
> > -extern void *efi_runtime_map;
> > -extern int nr_efi_runtime_map;
> > -extern struct kobject *efi_kobj;
> > +int efi_runtime_map_init(struct kobject *);
> > +int efi_runtime_map_setup(void *, int, u32);
Will change to void.
> > #endif
> >
> > #endif /* _LINUX_EFI_H */
> >
> > --
> > Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-16 6:02 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 6:02 UTC (permalink / raw)
To: Matt Fleming
Cc: Borislav Petkov, linux-kernel, linux-efi, x86, mjg59, hpa,
James.Bottomley, vgoyal, ebiederm, horms, kexec, greg,
toshi.kani
On 12/13/13 at 12:30pm, Matt Fleming wrote:
> I agree with Borislav that this should be invoked from efisubsys_init().
> Also Dave, there's nothing inherently x86-specific about runtime-map.c -
> we've been trying not to dump arch-specific code in
> drivers/firmware/efi/.
>
> How about something like this, just to give you an idea? This would
> allow the ARM/ia64 folks to enable this code if they want at some later
> date. But more than that, it makes the code more self-contained and uses
> some real interfaces instead of relying on global variables,
>
> (not compile tested)
>
> ---
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 94a1cbcf6e2e..f45ea41deae0 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -76,8 +76,8 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> {NULL_GUID, NULL, NULL},
> };
>
> -void *efi_runtime_map;
> -int nr_efi_runtime_map;
> +static void *efi_runtime_map;
> +static int nr_efi_runtime_map;
> static u64 efi_setup; /* efi setup_data physical address */
>
> /*
> @@ -1084,6 +1084,9 @@ void __init efi_enter_virtual_mode(void)
> }
> }
>
> + efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_map,
> + boot_params.efi_info.efi_memdesc_size);
> +
> BUG_ON(!efi.systab);
After this change, nr_efi_runtime_map become static, but since I'm moving
the parse_efi_setup to efi_64.c and nr_efi_runtime_map is set there for
kexec kernel use..
So I will just save the setup_data paddr as efi_setup in efi_64.c, and
move other code from parse_efi_setup() to below function which is called
in efi_init();
+static void __init efi_setup_init(void)
+{
+ struct setup_data *sd;
+
+ if (!efi_setup)
+ return;
+
+ sd = early_memremap(efi_setup, sizeof(struct setup_data));
+ if (!sd) {
+ pr_warn("early_memremap setup_data failed\n");
+ efi_setup = 0;
+ return;
+ }
+ efi_setup += sizeof(struct setup_data);
+ nr_efi_runtime_map = (sd->len - sizeof(struct efi_setup_data)) /
+ sizeof(efi_memory_desc_t);
+ early_memunmap(sd, sizeof(struct setup_data));
+}
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-16 6:02 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 6:02 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59, linux-efi, toshi.kani, greg, x86, kexec, linux-kernel,
James.Bottomley, horms, Borislav Petkov, ebiederm, hpa, vgoyal
On 12/13/13 at 12:30pm, Matt Fleming wrote:
> I agree with Borislav that this should be invoked from efisubsys_init().
> Also Dave, there's nothing inherently x86-specific about runtime-map.c -
> we've been trying not to dump arch-specific code in
> drivers/firmware/efi/.
>
> How about something like this, just to give you an idea? This would
> allow the ARM/ia64 folks to enable this code if they want at some later
> date. But more than that, it makes the code more self-contained and uses
> some real interfaces instead of relying on global variables,
>
> (not compile tested)
>
> ---
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 94a1cbcf6e2e..f45ea41deae0 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -76,8 +76,8 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> {NULL_GUID, NULL, NULL},
> };
>
> -void *efi_runtime_map;
> -int nr_efi_runtime_map;
> +static void *efi_runtime_map;
> +static int nr_efi_runtime_map;
> static u64 efi_setup; /* efi setup_data physical address */
>
> /*
> @@ -1084,6 +1084,9 @@ void __init efi_enter_virtual_mode(void)
> }
> }
>
> + efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_map,
> + boot_params.efi_info.efi_memdesc_size);
> +
> BUG_ON(!efi.systab);
After this change, nr_efi_runtime_map become static, but since I'm moving
the parse_efi_setup to efi_64.c and nr_efi_runtime_map is set there for
kexec kernel use..
So I will just save the setup_data paddr as efi_setup in efi_64.c, and
move other code from parse_efi_setup() to below function which is called
in efi_init();
+static void __init efi_setup_init(void)
+{
+ struct setup_data *sd;
+
+ if (!efi_setup)
+ return;
+
+ sd = early_memremap(efi_setup, sizeof(struct setup_data));
+ if (!sd) {
+ pr_warn("early_memremap setup_data failed\n");
+ efi_setup = 0;
+ return;
+ }
+ efi_setup += sizeof(struct setup_data);
+ nr_efi_runtime_map = (sd->len - sizeof(struct efi_setup_data)) /
+ sizeof(efi_memory_desc_t);
+ early_memunmap(sd, sizeof(struct setup_data));
+}
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 08/14] efi: export efi runtime memory mapping to sysfs
@ 2013-12-16 6:02 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 6:02 UTC (permalink / raw)
To: Matt Fleming
Cc: Borislav Petkov, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w, toshi.kani-VXdhtT5mjnY
On 12/13/13 at 12:30pm, Matt Fleming wrote:
> I agree with Borislav that this should be invoked from efisubsys_init().
> Also Dave, there's nothing inherently x86-specific about runtime-map.c -
> we've been trying not to dump arch-specific code in
> drivers/firmware/efi/.
>
> How about something like this, just to give you an idea? This would
> allow the ARM/ia64 folks to enable this code if they want at some later
> date. But more than that, it makes the code more self-contained and uses
> some real interfaces instead of relying on global variables,
>
> (not compile tested)
>
> ---
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 94a1cbcf6e2e..f45ea41deae0 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -76,8 +76,8 @@ static __initdata efi_config_table_type_t arch_tables[] = {
> {NULL_GUID, NULL, NULL},
> };
>
> -void *efi_runtime_map;
> -int nr_efi_runtime_map;
> +static void *efi_runtime_map;
> +static int nr_efi_runtime_map;
> static u64 efi_setup; /* efi setup_data physical address */
>
> /*
> @@ -1084,6 +1084,9 @@ void __init efi_enter_virtual_mode(void)
> }
> }
>
> + efi_runtime_map_setup(efi_runtime_map, nr_efi_runtime_map,
> + boot_params.efi_info.efi_memdesc_size);
> +
> BUG_ON(!efi.systab);
After this change, nr_efi_runtime_map become static, but since I'm moving
the parse_efi_setup to efi_64.c and nr_efi_runtime_map is set there for
kexec kernel use..
So I will just save the setup_data paddr as efi_setup in efi_64.c, and
move other code from parse_efi_setup() to below function which is called
in efi_init();
+static void __init efi_setup_init(void)
+{
+ struct setup_data *sd;
+
+ if (!efi_setup)
+ return;
+
+ sd = early_memremap(efi_setup, sizeof(struct setup_data));
+ if (!sd) {
+ pr_warn("early_memremap setup_data failed\n");
+ efi_setup = 0;
+ return;
+ }
+ efi_setup += sizeof(struct setup_data);
+ nr_efi_runtime_map = (sd->len - sizeof(struct efi_setup_data)) /
+ sizeof(efi_memory_desc_t);
+ early_memunmap(sd, sizeof(struct setup_data));
+}
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
When entering virtual mode, directly mapping the efi runtime ragions which
we passed in previously. And skip the step to call SetVirtualAddressMap.
Specially for HP z420 workstation we need save the smbios physical address.
The kernel boot sequence proceeds in the following order. Step 2
requires efi.smbios to be the physical address. However, I found that on
HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
we need set it back to the physical address with the smbios in
efi_setup_data. (When it is still the physical address, it simply sets
the same value.)
1. efi_init() - Set efi.smbios from EFI system table
2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
3. efi_enter_virtual_mode() - Map EFI ranges
Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
HP z420 workstation.
v2: refresh based on previous patch changes, code cleanup.
v3: use ioremap instead of phys_to_virt for efi_setup
v5: improve some code structure per comments from Matt
Boris: improve code structure, spell fix, etc.
Improve changelog from Toshi.
change the variable efi_setup to the physical address of efi setup_data
instead of the ioremapped virt address
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/include/asm/efi.h | 11 ++
arch/x86/include/uapi/asm/bootparam.h | 1 +
arch/x86/kernel/setup.c | 3 +
arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
4 files changed, 187 insertions(+), 23 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 9fbaeb2..73335a1 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -133,6 +133,17 @@ extern void efi_sync_low_kernel_mappings(void);
extern void efi_setup_page_tables(void);
extern void __init old_map_region(efi_memory_desc_t *md);
+struct efi_setup_data {
+ u64 fw_vendor;
+ u64 runtime;
+ u64 tables;
+ u64 smbios;
+ u64 reserved[8];
+ efi_memory_desc_t map[0];
+};
+
+extern void parse_efi_setup(u64 phys_addr);
+
#ifdef CONFIG_EFI
static inline bool efi_is_native(void)
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 9c3733c..64fe421 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -6,6 +6,7 @@
#define SETUP_E820_EXT 1
#define SETUP_DTB 2
#define SETUP_PCI 3
+#define SETUP_EFI 4
/* ram_size flags */
#define RAMDISK_IMAGE_START_MASK 0x07FF
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index cb233bc..b2b54cd 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -447,6 +447,9 @@ static void __init parse_setup_data(void)
case SETUP_DTB:
add_dtb(pa_data);
break;
+ case SETUP_EFI:
+ parse_efi_setup(pa_data);
+ break;
default:
break;
}
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 8289e0c..69a6ec2 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -78,6 +78,7 @@ static __initdata efi_config_table_type_t arch_tables[] = {
void *efi_runtime_map;
int nr_efi_runtime_map;
+static u64 efi_setup; /* efi setup_data physical address */
/*
* Returns 1 if 'facility' is enabled, 0 otherwise.
@@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
}
early_param("efi_no_storage_paranoia", setup_storage_paranoia);
+void __init parse_efi_setup(u64 phys_addr)
+{
+ struct setup_data *sd;
+
+ if (!efi_enabled(EFI_64BIT)) {
+ pr_warn("SETUP_EFI not supported on 32-bit\n");
+ return;
+ }
+
+ sd = early_memremap(phys_addr, sizeof(struct setup_data));
+ if (!sd) {
+ pr_warn("efi: early_memremap setup_data failed\n");
+ return;
+ }
+ efi_setup = phys_addr + sizeof(struct setup_data);
+ nr_efi_runtime_map = (sd->len - sizeof(struct efi_setup_data)) /
+ sizeof(efi_memory_desc_t);
+ early_memunmap(sd, sizeof(struct setup_data));
+}
static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
{
@@ -494,18 +514,28 @@ static int __init efi_systab_init(void *phys)
{
if (efi_enabled(EFI_64BIT)) {
efi_system_table_64_t *systab64;
+ struct efi_setup_data *data = NULL;
u64 tmp = 0;
+ if (efi_setup) {
+ data = early_memremap(efi_setup, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+ }
systab64 = early_memremap((unsigned long)phys,
sizeof(*systab64));
if (systab64 == NULL) {
pr_err("Couldn't map the system table!\n");
+ if (data)
+ early_memunmap(data, sizeof(*data));
return -ENOMEM;
}
efi_systab.hdr = systab64->hdr;
- efi_systab.fw_vendor = systab64->fw_vendor;
- tmp |= systab64->fw_vendor;
+
+ efi_systab.fw_vendor = data ? (unsigned long)data->fw_vendor :
+ systab64->fw_vendor;
+ tmp |= efi_systab.fw_vendor;
efi_systab.fw_revision = systab64->fw_revision;
efi_systab.con_in_handle = systab64->con_in_handle;
tmp |= systab64->con_in_handle;
@@ -519,15 +549,20 @@ static int __init efi_systab_init(void *phys)
tmp |= systab64->stderr_handle;
efi_systab.stderr = systab64->stderr;
tmp |= systab64->stderr;
- efi_systab.runtime = (void *)(unsigned long)systab64->runtime;
- tmp |= systab64->runtime;
+ efi_systab.runtime = data ?
+ (void *)(unsigned long)data->runtime :
+ (void *)(unsigned long)systab64->runtime;
+ tmp |= (unsigned long)efi_systab.runtime;
efi_systab.boottime = (void *)(unsigned long)systab64->boottime;
tmp |= systab64->boottime;
efi_systab.nr_tables = systab64->nr_tables;
- efi_systab.tables = systab64->tables;
- tmp |= systab64->tables;
+ efi_systab.tables = data ? (unsigned long)data->tables :
+ systab64->tables;
+ tmp |= efi_systab.tables;
early_memunmap(systab64, sizeof(*systab64));
+ if (data)
+ early_memunmap(data, sizeof(*data));
#ifdef CONFIG_X86_32
if (tmp >> 32) {
pr_err("EFI data located above 4GB, disabling EFI.\n");
@@ -631,6 +666,61 @@ static int __init efi_memmap_init(void)
return 0;
}
+/*
+ * For kexec kernel there's some special config table entries which could be
+ * converted to virtual addresses after entering virtual mode. In kexec kernel
+ * we need the physical addresses instead, thus passing them via setup_data
+ * and update the entries to physical addresses in this function.
+ *
+ * Currently only handles smbios which is necessary for HP z420.
+ */
+static int __init efi_reuse_config(u64 tables, int nr_tables)
+{
+ int i, sz, ret = 0;
+ void *p, *tablep;
+ struct efi_setup_data *data;
+
+ if (!efi_setup)
+ return 0;
+
+ if (!efi_enabled(EFI_64BIT))
+ return 0;
+
+ data = early_memremap(efi_setup, sizeof(*data));
+ if (!data) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ if (!data->smbios)
+ goto out_memremap;
+
+ sz = sizeof(efi_config_table_64_t);
+
+ p = tablep = early_memremap(tables, nr_tables * sz);
+ if (!p) {
+ pr_err("Could not map Configuration table!\n");
+ ret = -ENOMEM;
+ goto out_memremap;
+ }
+
+ for (i = 0; i < efi.systab->nr_tables; i++) {
+ efi_guid_t guid;
+
+ guid = ((efi_config_table_64_t *)p)->guid;
+
+ if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
+ ((efi_config_table_64_t *)p)->table = data->smbios;
+ p += sz;
+ }
+ early_memunmap(tablep, nr_tables * sz);
+
+out_memremap:
+ early_memunmap(data, sizeof(*data));
+out:
+ return ret;
+}
+
void __init efi_init(void)
{
efi_char16_t *c16;
@@ -676,6 +766,8 @@ void __init efi_init(void)
efi.systab->hdr.revision >> 16,
efi.systab->hdr.revision & 0xffff, vendor);
+ efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
+
if (efi_config_init(arch_tables))
return;
@@ -886,6 +978,50 @@ out_krealloc:
}
/*
+ * Map efi regions which was passed via setup_data. The virt_addr is a fixed
+ * addr which was used in first kernel in case kexec boot.
+ */
+static int __init map_regions_fixed(void)
+{
+ int i, s, ret = 0;
+ u64 end, systab;
+ unsigned long size;
+ efi_memory_desc_t *md;
+ struct efi_setup_data *data;
+
+ s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
+ data = early_memremap(efi_setup, s);
+ if (!data) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
+ efi_map_region_fixed(md); /* FIXME: add error handling */
+ size = md->num_pages << PAGE_SHIFT;
+ end = md->phys_addr + size;
+
+ systab = (u64) (unsigned long) efi_phys.systab;
+ if (md->phys_addr <= systab && systab < end) {
+ systab += md->virt_addr - md->phys_addr;
+ efi.systab = (efi_system_table_t *)(unsigned long)systab;
+ }
+ ret = save_runtime_map(md, i);
+ if (ret)
+ goto out_save_runtime;
+ }
+
+ early_memunmap(data, s);
+ return 0;
+
+out_save_runtime:
+ kfree(efi_runtime_map);
+ nr_efi_runtime_map = 0;
+ early_memunmap(data, s);
+out:
+ return ret;
+}
+
+/*
* This function will switch the EFI runtime services to virtual mode.
* Essentially, we look through the EFI memmap and map every region that
* has the runtime attribute bit set in its memory descriptor into the
@@ -901,12 +1037,16 @@ out_krealloc:
* so that we're in a different address space when calling a runtime
* function. For function arguments passing we do copy the PGDs of the
* kernel page table into ->trampoline_pgd prior to each call.
+ *
+ * Specially for kexec boot, efi runtime maps in previous kernel should
+ * be passed in via setup_data. In that case runtime ranges will be mapped
+ * to the same virtual addresses exactly same as the ones in previous kernel.
*/
void __init efi_enter_virtual_mode(void)
{
efi_status_t status;
void *new_memmap = NULL;
- int count = 0;
+ int err, count = 0;
efi.systab = NULL;
@@ -919,12 +1059,19 @@ void __init efi_enter_virtual_mode(void)
return;
}
- efi_merge_regions();
-
- new_memmap = efi_map_regions(&count);
- if (!new_memmap) {
- pr_err("Error reallocating memory, EFI runtime non-functional!\n");
- return;
+ if (efi_setup) {
+ err = map_regions_fixed();
+ if (err) {
+ pr_err("Error mapping runtime services, EFI runtime non-functional!\n");
+ return;
+ }
+ } else {
+ efi_merge_regions();
+ new_memmap = efi_map_regions(&count);
+ if (!new_memmap) {
+ pr_err("Error reallocating memory, EFI runtime non-functional!\n");
+ return;
+ }
}
BUG_ON(!efi.systab);
@@ -932,16 +1079,18 @@ void __init efi_enter_virtual_mode(void)
efi_setup_page_tables();
efi_sync_low_kernel_mappings();
- status = phys_efi_set_virtual_address_map(
- memmap.desc_size * count,
- memmap.desc_size,
- memmap.desc_version,
- (efi_memory_desc_t *)__pa(new_memmap));
-
- if (status != EFI_SUCCESS) {
- pr_alert("Unable to switch EFI into virtual mode "
- "(status=%lx)!\n", status);
- panic("EFI call to SetVirtualAddressMap() failed!");
+ if (!efi_setup) {
+ status = phys_efi_set_virtual_address_map(
+ memmap.desc_size * count,
+ memmap.desc_size,
+ memmap.desc_version,
+ (efi_memory_desc_t *)__pa(new_memmap));
+
+ if (status != EFI_SUCCESS) {
+ pr_alert("Unable to switch EFI into virtual mode (status=%lx)!\n",
+ status);
+ panic("EFI call to SetVirtualAddressMap() failed!");
+ }
}
/*
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
When entering virtual mode, directly mapping the efi runtime ragions which
we passed in previously. And skip the step to call SetVirtualAddressMap.
Specially for HP z420 workstation we need save the smbios physical address.
The kernel boot sequence proceeds in the following order. Step 2
requires efi.smbios to be the physical address. However, I found that on
HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
we need set it back to the physical address with the smbios in
efi_setup_data. (When it is still the physical address, it simply sets
the same value.)
1. efi_init() - Set efi.smbios from EFI system table
2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
3. efi_enter_virtual_mode() - Map EFI ranges
Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
HP z420 workstation.
v2: refresh based on previous patch changes, code cleanup.
v3: use ioremap instead of phys_to_virt for efi_setup
v5: improve some code structure per comments from Matt
Boris: improve code structure, spell fix, etc.
Improve changelog from Toshi.
change the variable efi_setup to the physical address of efi setup_data
instead of the ioremapped virt address
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/include/asm/efi.h | 11 ++
arch/x86/include/uapi/asm/bootparam.h | 1 +
arch/x86/kernel/setup.c | 3 +
arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
4 files changed, 187 insertions(+), 23 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 9fbaeb2..73335a1 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -133,6 +133,17 @@ extern void efi_sync_low_kernel_mappings(void);
extern void efi_setup_page_tables(void);
extern void __init old_map_region(efi_memory_desc_t *md);
+struct efi_setup_data {
+ u64 fw_vendor;
+ u64 runtime;
+ u64 tables;
+ u64 smbios;
+ u64 reserved[8];
+ efi_memory_desc_t map[0];
+};
+
+extern void parse_efi_setup(u64 phys_addr);
+
#ifdef CONFIG_EFI
static inline bool efi_is_native(void)
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 9c3733c..64fe421 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -6,6 +6,7 @@
#define SETUP_E820_EXT 1
#define SETUP_DTB 2
#define SETUP_PCI 3
+#define SETUP_EFI 4
/* ram_size flags */
#define RAMDISK_IMAGE_START_MASK 0x07FF
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index cb233bc..b2b54cd 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -447,6 +447,9 @@ static void __init parse_setup_data(void)
case SETUP_DTB:
add_dtb(pa_data);
break;
+ case SETUP_EFI:
+ parse_efi_setup(pa_data);
+ break;
default:
break;
}
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 8289e0c..69a6ec2 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -78,6 +78,7 @@ static __initdata efi_config_table_type_t arch_tables[] = {
void *efi_runtime_map;
int nr_efi_runtime_map;
+static u64 efi_setup; /* efi setup_data physical address */
/*
* Returns 1 if 'facility' is enabled, 0 otherwise.
@@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
}
early_param("efi_no_storage_paranoia", setup_storage_paranoia);
+void __init parse_efi_setup(u64 phys_addr)
+{
+ struct setup_data *sd;
+
+ if (!efi_enabled(EFI_64BIT)) {
+ pr_warn("SETUP_EFI not supported on 32-bit\n");
+ return;
+ }
+
+ sd = early_memremap(phys_addr, sizeof(struct setup_data));
+ if (!sd) {
+ pr_warn("efi: early_memremap setup_data failed\n");
+ return;
+ }
+ efi_setup = phys_addr + sizeof(struct setup_data);
+ nr_efi_runtime_map = (sd->len - sizeof(struct efi_setup_data)) /
+ sizeof(efi_memory_desc_t);
+ early_memunmap(sd, sizeof(struct setup_data));
+}
static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
{
@@ -494,18 +514,28 @@ static int __init efi_systab_init(void *phys)
{
if (efi_enabled(EFI_64BIT)) {
efi_system_table_64_t *systab64;
+ struct efi_setup_data *data = NULL;
u64 tmp = 0;
+ if (efi_setup) {
+ data = early_memremap(efi_setup, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+ }
systab64 = early_memremap((unsigned long)phys,
sizeof(*systab64));
if (systab64 == NULL) {
pr_err("Couldn't map the system table!\n");
+ if (data)
+ early_memunmap(data, sizeof(*data));
return -ENOMEM;
}
efi_systab.hdr = systab64->hdr;
- efi_systab.fw_vendor = systab64->fw_vendor;
- tmp |= systab64->fw_vendor;
+
+ efi_systab.fw_vendor = data ? (unsigned long)data->fw_vendor :
+ systab64->fw_vendor;
+ tmp |= efi_systab.fw_vendor;
efi_systab.fw_revision = systab64->fw_revision;
efi_systab.con_in_handle = systab64->con_in_handle;
tmp |= systab64->con_in_handle;
@@ -519,15 +549,20 @@ static int __init efi_systab_init(void *phys)
tmp |= systab64->stderr_handle;
efi_systab.stderr = systab64->stderr;
tmp |= systab64->stderr;
- efi_systab.runtime = (void *)(unsigned long)systab64->runtime;
- tmp |= systab64->runtime;
+ efi_systab.runtime = data ?
+ (void *)(unsigned long)data->runtime :
+ (void *)(unsigned long)systab64->runtime;
+ tmp |= (unsigned long)efi_systab.runtime;
efi_systab.boottime = (void *)(unsigned long)systab64->boottime;
tmp |= systab64->boottime;
efi_systab.nr_tables = systab64->nr_tables;
- efi_systab.tables = systab64->tables;
- tmp |= systab64->tables;
+ efi_systab.tables = data ? (unsigned long)data->tables :
+ systab64->tables;
+ tmp |= efi_systab.tables;
early_memunmap(systab64, sizeof(*systab64));
+ if (data)
+ early_memunmap(data, sizeof(*data));
#ifdef CONFIG_X86_32
if (tmp >> 32) {
pr_err("EFI data located above 4GB, disabling EFI.\n");
@@ -631,6 +666,61 @@ static int __init efi_memmap_init(void)
return 0;
}
+/*
+ * For kexec kernel there's some special config table entries which could be
+ * converted to virtual addresses after entering virtual mode. In kexec kernel
+ * we need the physical addresses instead, thus passing them via setup_data
+ * and update the entries to physical addresses in this function.
+ *
+ * Currently only handles smbios which is necessary for HP z420.
+ */
+static int __init efi_reuse_config(u64 tables, int nr_tables)
+{
+ int i, sz, ret = 0;
+ void *p, *tablep;
+ struct efi_setup_data *data;
+
+ if (!efi_setup)
+ return 0;
+
+ if (!efi_enabled(EFI_64BIT))
+ return 0;
+
+ data = early_memremap(efi_setup, sizeof(*data));
+ if (!data) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ if (!data->smbios)
+ goto out_memremap;
+
+ sz = sizeof(efi_config_table_64_t);
+
+ p = tablep = early_memremap(tables, nr_tables * sz);
+ if (!p) {
+ pr_err("Could not map Configuration table!\n");
+ ret = -ENOMEM;
+ goto out_memremap;
+ }
+
+ for (i = 0; i < efi.systab->nr_tables; i++) {
+ efi_guid_t guid;
+
+ guid = ((efi_config_table_64_t *)p)->guid;
+
+ if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
+ ((efi_config_table_64_t *)p)->table = data->smbios;
+ p += sz;
+ }
+ early_memunmap(tablep, nr_tables * sz);
+
+out_memremap:
+ early_memunmap(data, sizeof(*data));
+out:
+ return ret;
+}
+
void __init efi_init(void)
{
efi_char16_t *c16;
@@ -676,6 +766,8 @@ void __init efi_init(void)
efi.systab->hdr.revision >> 16,
efi.systab->hdr.revision & 0xffff, vendor);
+ efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
+
if (efi_config_init(arch_tables))
return;
@@ -886,6 +978,50 @@ out_krealloc:
}
/*
+ * Map efi regions which was passed via setup_data. The virt_addr is a fixed
+ * addr which was used in first kernel in case kexec boot.
+ */
+static int __init map_regions_fixed(void)
+{
+ int i, s, ret = 0;
+ u64 end, systab;
+ unsigned long size;
+ efi_memory_desc_t *md;
+ struct efi_setup_data *data;
+
+ s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
+ data = early_memremap(efi_setup, s);
+ if (!data) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
+ efi_map_region_fixed(md); /* FIXME: add error handling */
+ size = md->num_pages << PAGE_SHIFT;
+ end = md->phys_addr + size;
+
+ systab = (u64) (unsigned long) efi_phys.systab;
+ if (md->phys_addr <= systab && systab < end) {
+ systab += md->virt_addr - md->phys_addr;
+ efi.systab = (efi_system_table_t *)(unsigned long)systab;
+ }
+ ret = save_runtime_map(md, i);
+ if (ret)
+ goto out_save_runtime;
+ }
+
+ early_memunmap(data, s);
+ return 0;
+
+out_save_runtime:
+ kfree(efi_runtime_map);
+ nr_efi_runtime_map = 0;
+ early_memunmap(data, s);
+out:
+ return ret;
+}
+
+/*
* This function will switch the EFI runtime services to virtual mode.
* Essentially, we look through the EFI memmap and map every region that
* has the runtime attribute bit set in its memory descriptor into the
@@ -901,12 +1037,16 @@ out_krealloc:
* so that we're in a different address space when calling a runtime
* function. For function arguments passing we do copy the PGDs of the
* kernel page table into ->trampoline_pgd prior to each call.
+ *
+ * Specially for kexec boot, efi runtime maps in previous kernel should
+ * be passed in via setup_data. In that case runtime ranges will be mapped
+ * to the same virtual addresses exactly same as the ones in previous kernel.
*/
void __init efi_enter_virtual_mode(void)
{
efi_status_t status;
void *new_memmap = NULL;
- int count = 0;
+ int err, count = 0;
efi.systab = NULL;
@@ -919,12 +1059,19 @@ void __init efi_enter_virtual_mode(void)
return;
}
- efi_merge_regions();
-
- new_memmap = efi_map_regions(&count);
- if (!new_memmap) {
- pr_err("Error reallocating memory, EFI runtime non-functional!\n");
- return;
+ if (efi_setup) {
+ err = map_regions_fixed();
+ if (err) {
+ pr_err("Error mapping runtime services, EFI runtime non-functional!\n");
+ return;
+ }
+ } else {
+ efi_merge_regions();
+ new_memmap = efi_map_regions(&count);
+ if (!new_memmap) {
+ pr_err("Error reallocating memory, EFI runtime non-functional!\n");
+ return;
+ }
}
BUG_ON(!efi.systab);
@@ -932,16 +1079,18 @@ void __init efi_enter_virtual_mode(void)
efi_setup_page_tables();
efi_sync_low_kernel_mappings();
- status = phys_efi_set_virtual_address_map(
- memmap.desc_size * count,
- memmap.desc_size,
- memmap.desc_version,
- (efi_memory_desc_t *)__pa(new_memmap));
-
- if (status != EFI_SUCCESS) {
- pr_alert("Unable to switch EFI into virtual mode "
- "(status=%lx)!\n", status);
- panic("EFI call to SetVirtualAddressMap() failed!");
+ if (!efi_setup) {
+ status = phys_efi_set_virtual_address_map(
+ memmap.desc_size * count,
+ memmap.desc_size,
+ memmap.desc_version,
+ (efi_memory_desc_t *)__pa(new_memmap));
+
+ if (status != EFI_SUCCESS) {
+ pr_alert("Unable to switch EFI into virtual mode (status=%lx)!\n",
+ status);
+ panic("EFI call to SetVirtualAddressMap() failed!");
+ }
}
/*
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
When entering virtual mode, directly mapping the efi runtime ragions which
we passed in previously. And skip the step to call SetVirtualAddressMap.
Specially for HP z420 workstation we need save the smbios physical address.
The kernel boot sequence proceeds in the following order. Step 2
requires efi.smbios to be the physical address. However, I found that on
HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
we need set it back to the physical address with the smbios in
efi_setup_data. (When it is still the physical address, it simply sets
the same value.)
1. efi_init() - Set efi.smbios from EFI system table
2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
3. efi_enter_virtual_mode() - Map EFI ranges
Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
HP z420 workstation.
v2: refresh based on previous patch changes, code cleanup.
v3: use ioremap instead of phys_to_virt for efi_setup
v5: improve some code structure per comments from Matt
Boris: improve code structure, spell fix, etc.
Improve changelog from Toshi.
change the variable efi_setup to the physical address of efi setup_data
instead of the ioremapped virt address
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
arch/x86/include/asm/efi.h | 11 ++
arch/x86/include/uapi/asm/bootparam.h | 1 +
arch/x86/kernel/setup.c | 3 +
arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
4 files changed, 187 insertions(+), 23 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 9fbaeb2..73335a1 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -133,6 +133,17 @@ extern void efi_sync_low_kernel_mappings(void);
extern void efi_setup_page_tables(void);
extern void __init old_map_region(efi_memory_desc_t *md);
+struct efi_setup_data {
+ u64 fw_vendor;
+ u64 runtime;
+ u64 tables;
+ u64 smbios;
+ u64 reserved[8];
+ efi_memory_desc_t map[0];
+};
+
+extern void parse_efi_setup(u64 phys_addr);
+
#ifdef CONFIG_EFI
static inline bool efi_is_native(void)
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 9c3733c..64fe421 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -6,6 +6,7 @@
#define SETUP_E820_EXT 1
#define SETUP_DTB 2
#define SETUP_PCI 3
+#define SETUP_EFI 4
/* ram_size flags */
#define RAMDISK_IMAGE_START_MASK 0x07FF
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index cb233bc..b2b54cd 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -447,6 +447,9 @@ static void __init parse_setup_data(void)
case SETUP_DTB:
add_dtb(pa_data);
break;
+ case SETUP_EFI:
+ parse_efi_setup(pa_data);
+ break;
default:
break;
}
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 8289e0c..69a6ec2 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -78,6 +78,7 @@ static __initdata efi_config_table_type_t arch_tables[] = {
void *efi_runtime_map;
int nr_efi_runtime_map;
+static u64 efi_setup; /* efi setup_data physical address */
/*
* Returns 1 if 'facility' is enabled, 0 otherwise.
@@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
}
early_param("efi_no_storage_paranoia", setup_storage_paranoia);
+void __init parse_efi_setup(u64 phys_addr)
+{
+ struct setup_data *sd;
+
+ if (!efi_enabled(EFI_64BIT)) {
+ pr_warn("SETUP_EFI not supported on 32-bit\n");
+ return;
+ }
+
+ sd = early_memremap(phys_addr, sizeof(struct setup_data));
+ if (!sd) {
+ pr_warn("efi: early_memremap setup_data failed\n");
+ return;
+ }
+ efi_setup = phys_addr + sizeof(struct setup_data);
+ nr_efi_runtime_map = (sd->len - sizeof(struct efi_setup_data)) /
+ sizeof(efi_memory_desc_t);
+ early_memunmap(sd, sizeof(struct setup_data));
+}
static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
{
@@ -494,18 +514,28 @@ static int __init efi_systab_init(void *phys)
{
if (efi_enabled(EFI_64BIT)) {
efi_system_table_64_t *systab64;
+ struct efi_setup_data *data = NULL;
u64 tmp = 0;
+ if (efi_setup) {
+ data = early_memremap(efi_setup, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+ }
systab64 = early_memremap((unsigned long)phys,
sizeof(*systab64));
if (systab64 == NULL) {
pr_err("Couldn't map the system table!\n");
+ if (data)
+ early_memunmap(data, sizeof(*data));
return -ENOMEM;
}
efi_systab.hdr = systab64->hdr;
- efi_systab.fw_vendor = systab64->fw_vendor;
- tmp |= systab64->fw_vendor;
+
+ efi_systab.fw_vendor = data ? (unsigned long)data->fw_vendor :
+ systab64->fw_vendor;
+ tmp |= efi_systab.fw_vendor;
efi_systab.fw_revision = systab64->fw_revision;
efi_systab.con_in_handle = systab64->con_in_handle;
tmp |= systab64->con_in_handle;
@@ -519,15 +549,20 @@ static int __init efi_systab_init(void *phys)
tmp |= systab64->stderr_handle;
efi_systab.stderr = systab64->stderr;
tmp |= systab64->stderr;
- efi_systab.runtime = (void *)(unsigned long)systab64->runtime;
- tmp |= systab64->runtime;
+ efi_systab.runtime = data ?
+ (void *)(unsigned long)data->runtime :
+ (void *)(unsigned long)systab64->runtime;
+ tmp |= (unsigned long)efi_systab.runtime;
efi_systab.boottime = (void *)(unsigned long)systab64->boottime;
tmp |= systab64->boottime;
efi_systab.nr_tables = systab64->nr_tables;
- efi_systab.tables = systab64->tables;
- tmp |= systab64->tables;
+ efi_systab.tables = data ? (unsigned long)data->tables :
+ systab64->tables;
+ tmp |= efi_systab.tables;
early_memunmap(systab64, sizeof(*systab64));
+ if (data)
+ early_memunmap(data, sizeof(*data));
#ifdef CONFIG_X86_32
if (tmp >> 32) {
pr_err("EFI data located above 4GB, disabling EFI.\n");
@@ -631,6 +666,61 @@ static int __init efi_memmap_init(void)
return 0;
}
+/*
+ * For kexec kernel there's some special config table entries which could be
+ * converted to virtual addresses after entering virtual mode. In kexec kernel
+ * we need the physical addresses instead, thus passing them via setup_data
+ * and update the entries to physical addresses in this function.
+ *
+ * Currently only handles smbios which is necessary for HP z420.
+ */
+static int __init efi_reuse_config(u64 tables, int nr_tables)
+{
+ int i, sz, ret = 0;
+ void *p, *tablep;
+ struct efi_setup_data *data;
+
+ if (!efi_setup)
+ return 0;
+
+ if (!efi_enabled(EFI_64BIT))
+ return 0;
+
+ data = early_memremap(efi_setup, sizeof(*data));
+ if (!data) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ if (!data->smbios)
+ goto out_memremap;
+
+ sz = sizeof(efi_config_table_64_t);
+
+ p = tablep = early_memremap(tables, nr_tables * sz);
+ if (!p) {
+ pr_err("Could not map Configuration table!\n");
+ ret = -ENOMEM;
+ goto out_memremap;
+ }
+
+ for (i = 0; i < efi.systab->nr_tables; i++) {
+ efi_guid_t guid;
+
+ guid = ((efi_config_table_64_t *)p)->guid;
+
+ if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
+ ((efi_config_table_64_t *)p)->table = data->smbios;
+ p += sz;
+ }
+ early_memunmap(tablep, nr_tables * sz);
+
+out_memremap:
+ early_memunmap(data, sizeof(*data));
+out:
+ return ret;
+}
+
void __init efi_init(void)
{
efi_char16_t *c16;
@@ -676,6 +766,8 @@ void __init efi_init(void)
efi.systab->hdr.revision >> 16,
efi.systab->hdr.revision & 0xffff, vendor);
+ efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
+
if (efi_config_init(arch_tables))
return;
@@ -886,6 +978,50 @@ out_krealloc:
}
/*
+ * Map efi regions which was passed via setup_data. The virt_addr is a fixed
+ * addr which was used in first kernel in case kexec boot.
+ */
+static int __init map_regions_fixed(void)
+{
+ int i, s, ret = 0;
+ u64 end, systab;
+ unsigned long size;
+ efi_memory_desc_t *md;
+ struct efi_setup_data *data;
+
+ s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
+ data = early_memremap(efi_setup, s);
+ if (!data) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
+ efi_map_region_fixed(md); /* FIXME: add error handling */
+ size = md->num_pages << PAGE_SHIFT;
+ end = md->phys_addr + size;
+
+ systab = (u64) (unsigned long) efi_phys.systab;
+ if (md->phys_addr <= systab && systab < end) {
+ systab += md->virt_addr - md->phys_addr;
+ efi.systab = (efi_system_table_t *)(unsigned long)systab;
+ }
+ ret = save_runtime_map(md, i);
+ if (ret)
+ goto out_save_runtime;
+ }
+
+ early_memunmap(data, s);
+ return 0;
+
+out_save_runtime:
+ kfree(efi_runtime_map);
+ nr_efi_runtime_map = 0;
+ early_memunmap(data, s);
+out:
+ return ret;
+}
+
+/*
* This function will switch the EFI runtime services to virtual mode.
* Essentially, we look through the EFI memmap and map every region that
* has the runtime attribute bit set in its memory descriptor into the
@@ -901,12 +1037,16 @@ out_krealloc:
* so that we're in a different address space when calling a runtime
* function. For function arguments passing we do copy the PGDs of the
* kernel page table into ->trampoline_pgd prior to each call.
+ *
+ * Specially for kexec boot, efi runtime maps in previous kernel should
+ * be passed in via setup_data. In that case runtime ranges will be mapped
+ * to the same virtual addresses exactly same as the ones in previous kernel.
*/
void __init efi_enter_virtual_mode(void)
{
efi_status_t status;
void *new_memmap = NULL;
- int count = 0;
+ int err, count = 0;
efi.systab = NULL;
@@ -919,12 +1059,19 @@ void __init efi_enter_virtual_mode(void)
return;
}
- efi_merge_regions();
-
- new_memmap = efi_map_regions(&count);
- if (!new_memmap) {
- pr_err("Error reallocating memory, EFI runtime non-functional!\n");
- return;
+ if (efi_setup) {
+ err = map_regions_fixed();
+ if (err) {
+ pr_err("Error mapping runtime services, EFI runtime non-functional!\n");
+ return;
+ }
+ } else {
+ efi_merge_regions();
+ new_memmap = efi_map_regions(&count);
+ if (!new_memmap) {
+ pr_err("Error reallocating memory, EFI runtime non-functional!\n");
+ return;
+ }
}
BUG_ON(!efi.systab);
@@ -932,16 +1079,18 @@ void __init efi_enter_virtual_mode(void)
efi_setup_page_tables();
efi_sync_low_kernel_mappings();
- status = phys_efi_set_virtual_address_map(
- memmap.desc_size * count,
- memmap.desc_size,
- memmap.desc_version,
- (efi_memory_desc_t *)__pa(new_memmap));
-
- if (status != EFI_SUCCESS) {
- pr_alert("Unable to switch EFI into virtual mode "
- "(status=%lx)!\n", status);
- panic("EFI call to SetVirtualAddressMap() failed!");
+ if (!efi_setup) {
+ status = phys_efi_set_virtual_address_map(
+ memmap.desc_size * count,
+ memmap.desc_size,
+ memmap.desc_version,
+ (efi_memory_desc_t *)__pa(new_memmap));
+
+ if (status != EFI_SUCCESS) {
+ pr_alert("Unable to switch EFI into virtual mode (status=%lx)!\n",
+ status);
+ panic("EFI call to SetVirtualAddressMap() failed!");
+ }
}
/*
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-11 12:13 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 12:13 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, bp, greg, toshi.kani
On Mon, 09 Dec, at 05:42:22PM, Dave Young wrote:
> Add a new setup_data type SETUP_EFI for kexec use.
> Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
>
> When entering virtual mode, directly mapping the efi runtime ragions which
> we passed in previously. And skip the step to call SetVirtualAddressMap.
>
> Specially for HP z420 workstation we need save the smbios physical address.
> The kernel boot sequence proceeds in the following order. Step 2
> requires efi.smbios to be the physical address. However, I found that on
> HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
> we need set it back to the physical address with the smbios in
> efi_setup_data. (When it is still the physical address, it simply sets
> the same value.)
>
> 1. efi_init() - Set efi.smbios from EFI system table
> 2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
> 3. efi_enter_virtual_mode() - Map EFI ranges
>
> Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
> HP z420 workstation.
>
> v2: refresh based on previous patch changes, code cleanup.
> v3: use ioremap instead of phys_to_virt for efi_setup
> v5: improve some code structure per comments from Matt
> Boris: improve code structure, spell fix, etc.
> Improve changelog from Toshi.
> change the variable efi_setup to the physical address of efi setup_data
> instead of the ioremapped virt address
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/include/asm/efi.h | 11 ++
> arch/x86/include/uapi/asm/bootparam.h | 1 +
> arch/x86/kernel/setup.c | 3 +
> arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
> 4 files changed, 187 insertions(+), 23 deletions(-)
[...]
> @@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
> }
> early_param("efi_no_storage_paranoia", setup_storage_paranoia);
>
> +void __init parse_efi_setup(u64 phys_addr)
> +{
> + struct setup_data *sd;
> +
> + if (!efi_enabled(EFI_64BIT)) {
> + pr_warn("SETUP_EFI not supported on 32-bit\n");
> + return;
> + }
> +
> + sd = early_memremap(phys_addr, sizeof(struct setup_data));
> + if (!sd) {
> + pr_warn("efi: early_memremap setup_data failed\n");
You shouldn't need the "efi:" prefix in the message.
> @@ -676,6 +766,8 @@ void __init efi_init(void)
> efi.systab->hdr.revision >> 16,
> efi.systab->hdr.revision & 0xffff, vendor);
>
> + efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
> +
Please check the return value.
> if (efi_config_init(arch_tables))
> return;
>
> @@ -886,6 +978,50 @@ out_krealloc:
> }
>
> /*
> + * Map efi regions which was passed via setup_data. The virt_addr is a fixed
> + * addr which was used in first kernel in case kexec boot.
> + */
> +static int __init map_regions_fixed(void)
> +{
> + int i, s, ret = 0;
> + u64 end, systab;
> + unsigned long size;
> + efi_memory_desc_t *md;
> + struct efi_setup_data *data;
> +
> + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> + data = early_memremap(efi_setup, s);
> + if (!data) {
> + ret = -ENOMEM;
> + goto out;
> + }
> + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> + efi_map_region_fixed(md); /* FIXME: add error handling */
Oops. Please fix this ;-)
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-11 12:13 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 12:13 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, greg, x86, kexec, linux-kernel,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
On Mon, 09 Dec, at 05:42:22PM, Dave Young wrote:
> Add a new setup_data type SETUP_EFI for kexec use.
> Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
>
> When entering virtual mode, directly mapping the efi runtime ragions which
> we passed in previously. And skip the step to call SetVirtualAddressMap.
>
> Specially for HP z420 workstation we need save the smbios physical address.
> The kernel boot sequence proceeds in the following order. Step 2
> requires efi.smbios to be the physical address. However, I found that on
> HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
> we need set it back to the physical address with the smbios in
> efi_setup_data. (When it is still the physical address, it simply sets
> the same value.)
>
> 1. efi_init() - Set efi.smbios from EFI system table
> 2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
> 3. efi_enter_virtual_mode() - Map EFI ranges
>
> Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
> HP z420 workstation.
>
> v2: refresh based on previous patch changes, code cleanup.
> v3: use ioremap instead of phys_to_virt for efi_setup
> v5: improve some code structure per comments from Matt
> Boris: improve code structure, spell fix, etc.
> Improve changelog from Toshi.
> change the variable efi_setup to the physical address of efi setup_data
> instead of the ioremapped virt address
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/include/asm/efi.h | 11 ++
> arch/x86/include/uapi/asm/bootparam.h | 1 +
> arch/x86/kernel/setup.c | 3 +
> arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
> 4 files changed, 187 insertions(+), 23 deletions(-)
[...]
> @@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
> }
> early_param("efi_no_storage_paranoia", setup_storage_paranoia);
>
> +void __init parse_efi_setup(u64 phys_addr)
> +{
> + struct setup_data *sd;
> +
> + if (!efi_enabled(EFI_64BIT)) {
> + pr_warn("SETUP_EFI not supported on 32-bit\n");
> + return;
> + }
> +
> + sd = early_memremap(phys_addr, sizeof(struct setup_data));
> + if (!sd) {
> + pr_warn("efi: early_memremap setup_data failed\n");
You shouldn't need the "efi:" prefix in the message.
> @@ -676,6 +766,8 @@ void __init efi_init(void)
> efi.systab->hdr.revision >> 16,
> efi.systab->hdr.revision & 0xffff, vendor);
>
> + efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
> +
Please check the return value.
> if (efi_config_init(arch_tables))
> return;
>
> @@ -886,6 +978,50 @@ out_krealloc:
> }
>
> /*
> + * Map efi regions which was passed via setup_data. The virt_addr is a fixed
> + * addr which was used in first kernel in case kexec boot.
> + */
> +static int __init map_regions_fixed(void)
> +{
> + int i, s, ret = 0;
> + u64 end, systab;
> + unsigned long size;
> + efi_memory_desc_t *md;
> + struct efi_setup_data *data;
> +
> + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> + data = early_memremap(efi_setup, s);
> + if (!data) {
> + ret = -ENOMEM;
> + goto out;
> + }
> + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> + efi_map_region_fixed(md); /* FIXME: add error handling */
Oops. Please fix this ;-)
--
Matt Fleming, Intel Open Source Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-11 12:13 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 12:13 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bp-Gina5bIWoIWzQB+pC5nmwQ, greg-U8xfFu+wG4EAvxtiuMwx3w,
toshi.kani-VXdhtT5mjnY
On Mon, 09 Dec, at 05:42:22PM, Dave Young wrote:
> Add a new setup_data type SETUP_EFI for kexec use.
> Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
>
> When entering virtual mode, directly mapping the efi runtime ragions which
> we passed in previously. And skip the step to call SetVirtualAddressMap.
>
> Specially for HP z420 workstation we need save the smbios physical address.
> The kernel boot sequence proceeds in the following order. Step 2
> requires efi.smbios to be the physical address. However, I found that on
> HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
> we need set it back to the physical address with the smbios in
> efi_setup_data. (When it is still the physical address, it simply sets
> the same value.)
>
> 1. efi_init() - Set efi.smbios from EFI system table
> 2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
> 3. efi_enter_virtual_mode() - Map EFI ranges
>
> Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
> HP z420 workstation.
>
> v2: refresh based on previous patch changes, code cleanup.
> v3: use ioremap instead of phys_to_virt for efi_setup
> v5: improve some code structure per comments from Matt
> Boris: improve code structure, spell fix, etc.
> Improve changelog from Toshi.
> change the variable efi_setup to the physical address of efi setup_data
> instead of the ioremapped virt address
>
> Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> arch/x86/include/asm/efi.h | 11 ++
> arch/x86/include/uapi/asm/bootparam.h | 1 +
> arch/x86/kernel/setup.c | 3 +
> arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
> 4 files changed, 187 insertions(+), 23 deletions(-)
[...]
> @@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
> }
> early_param("efi_no_storage_paranoia", setup_storage_paranoia);
>
> +void __init parse_efi_setup(u64 phys_addr)
> +{
> + struct setup_data *sd;
> +
> + if (!efi_enabled(EFI_64BIT)) {
> + pr_warn("SETUP_EFI not supported on 32-bit\n");
> + return;
> + }
> +
> + sd = early_memremap(phys_addr, sizeof(struct setup_data));
> + if (!sd) {
> + pr_warn("efi: early_memremap setup_data failed\n");
You shouldn't need the "efi:" prefix in the message.
> @@ -676,6 +766,8 @@ void __init efi_init(void)
> efi.systab->hdr.revision >> 16,
> efi.systab->hdr.revision & 0xffff, vendor);
>
> + efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
> +
Please check the return value.
> if (efi_config_init(arch_tables))
> return;
>
> @@ -886,6 +978,50 @@ out_krealloc:
> }
>
> /*
> + * Map efi regions which was passed via setup_data. The virt_addr is a fixed
> + * addr which was used in first kernel in case kexec boot.
> + */
> +static int __init map_regions_fixed(void)
> +{
> + int i, s, ret = 0;
> + u64 end, systab;
> + unsigned long size;
> + efi_memory_desc_t *md;
> + struct efi_setup_data *data;
> +
> + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> + data = early_memremap(efi_setup, s);
> + if (!data) {
> + ret = -ENOMEM;
> + goto out;
> + }
> + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> + efi_map_region_fixed(md); /* FIXME: add error handling */
Oops. Please fix this ;-)
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-11 14:05 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 14:05 UTC (permalink / raw)
To: Matt Fleming
Cc: Dave Young, linux-kernel, linux-efi, x86, mjg59, hpa,
James.Bottomley, vgoyal, ebiederm, horms, kexec, greg,
toshi.kani
On Wed, Dec 11, 2013 at 12:13:52PM +0000, Matt Fleming wrote:
> > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > + efi_map_region_fixed(md); /* FIXME: add error handling */
>
> Oops. Please fix this ;-)
Yeah, this is on my TODO as it wraps around __map_region, the latter
needing to propagate error codes.
I'll take care of it once you merge Dave's patchset.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-11 14:05 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 14:05 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59, linux-efi, toshi.kani, greg, x86, kexec, linux-kernel,
James.Bottomley, horms, ebiederm, hpa, Dave Young, vgoyal
On Wed, Dec 11, 2013 at 12:13:52PM +0000, Matt Fleming wrote:
> > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > + efi_map_region_fixed(md); /* FIXME: add error handling */
>
> Oops. Please fix this ;-)
Yeah, this is on my TODO as it wraps around __map_region, the latter
needing to propagate error codes.
I'll take care of it once you merge Dave's patchset.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-11 14:05 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 14:05 UTC (permalink / raw)
To: Matt Fleming
Cc: Dave Young, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w, toshi.kani-VXdhtT5mjnY
On Wed, Dec 11, 2013 at 12:13:52PM +0000, Matt Fleming wrote:
> > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > + efi_map_region_fixed(md); /* FIXME: add error handling */
>
> Oops. Please fix this ;-)
Yeah, this is on my TODO as it wraps around __map_region, the latter
needing to propagate error codes.
I'll take care of it once you merge Dave's patchset.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 2:11 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:11 UTC (permalink / raw)
To: Borislav Petkov
Cc: Matt Fleming, linux-kernel, linux-efi, x86, mjg59, hpa,
James.Bottomley, vgoyal, ebiederm, horms, kexec, greg,
toshi.kani
On 12/11/13 at 03:05pm, Borislav Petkov wrote:
> On Wed, Dec 11, 2013 at 12:13:52PM +0000, Matt Fleming wrote:
> > > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > > + efi_map_region_fixed(md); /* FIXME: add error handling */
> >
> > Oops. Please fix this ;-)
>
> Yeah, this is on my TODO as it wraps around __map_region, the latter
> needing to propagate error codes.
>
> I'll take care of it once you merge Dave's patchset.
Thanks Boris..
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 2:11 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:11 UTC (permalink / raw)
To: Borislav Petkov
Cc: Matt Fleming, linux-efi, toshi.kani, mjg59, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On 12/11/13 at 03:05pm, Borislav Petkov wrote:
> On Wed, Dec 11, 2013 at 12:13:52PM +0000, Matt Fleming wrote:
> > > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > > + efi_map_region_fixed(md); /* FIXME: add error handling */
> >
> > Oops. Please fix this ;-)
>
> Yeah, this is on my TODO as it wraps around __map_region, the latter
> needing to propagate error codes.
>
> I'll take care of it once you merge Dave's patchset.
Thanks Boris..
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 2:11 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:11 UTC (permalink / raw)
To: Borislav Petkov
Cc: Matt Fleming, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w, toshi.kani-VXdhtT5mjnY
On 12/11/13 at 03:05pm, Borislav Petkov wrote:
> On Wed, Dec 11, 2013 at 12:13:52PM +0000, Matt Fleming wrote:
> > > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > > + efi_map_region_fixed(md); /* FIXME: add error handling */
> >
> > Oops. Please fix this ;-)
>
> Yeah, this is on my TODO as it wraps around __map_region, the latter
> needing to propagate error codes.
>
> I'll take care of it once you merge Dave's patchset.
Thanks Boris..
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 2:10 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:10 UTC (permalink / raw)
To: Matt Fleming
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, bp, greg, toshi.kani
On 12/11/13 at 12:13pm, Matt Fleming wrote:
> On Mon, 09 Dec, at 05:42:22PM, Dave Young wrote:
> > Add a new setup_data type SETUP_EFI for kexec use.
> > Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
> >
> > When entering virtual mode, directly mapping the efi runtime ragions which
> > we passed in previously. And skip the step to call SetVirtualAddressMap.
> >
> > Specially for HP z420 workstation we need save the smbios physical address.
> > The kernel boot sequence proceeds in the following order. Step 2
> > requires efi.smbios to be the physical address. However, I found that on
> > HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
> > we need set it back to the physical address with the smbios in
> > efi_setup_data. (When it is still the physical address, it simply sets
> > the same value.)
> >
> > 1. efi_init() - Set efi.smbios from EFI system table
> > 2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
> > 3. efi_enter_virtual_mode() - Map EFI ranges
> >
> > Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
> > HP z420 workstation.
> >
> > v2: refresh based on previous patch changes, code cleanup.
> > v3: use ioremap instead of phys_to_virt for efi_setup
> > v5: improve some code structure per comments from Matt
> > Boris: improve code structure, spell fix, etc.
> > Improve changelog from Toshi.
> > change the variable efi_setup to the physical address of efi setup_data
> > instead of the ioremapped virt address
> >
> > Signed-off-by: Dave Young <dyoung@redhat.com>
> > ---
> > arch/x86/include/asm/efi.h | 11 ++
> > arch/x86/include/uapi/asm/bootparam.h | 1 +
> > arch/x86/kernel/setup.c | 3 +
> > arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
> > 4 files changed, 187 insertions(+), 23 deletions(-)
>
> [...]
>
> > @@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
> > }
> > early_param("efi_no_storage_paranoia", setup_storage_paranoia);
> >
> > +void __init parse_efi_setup(u64 phys_addr)
> > +{
> > + struct setup_data *sd;
> > +
> > + if (!efi_enabled(EFI_64BIT)) {
> > + pr_warn("SETUP_EFI not supported on 32-bit\n");
> > + return;
> > + }
> > +
> > + sd = early_memremap(phys_addr, sizeof(struct setup_data));
> > + if (!sd) {
> > + pr_warn("efi: early_memremap setup_data failed\n");
>
> You shouldn't need the "efi:" prefix in the message.
Hmm, remove efi: looks better, will update.
>
> > @@ -676,6 +766,8 @@ void __init efi_init(void)
> > efi.systab->hdr.revision >> 16,
> > efi.systab->hdr.revision & 0xffff, vendor);
> >
> > + efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
> > +
>
> Please check the return value.
I missed this one, will update.
>
> > if (efi_config_init(arch_tables))
> > return;
> >
> > @@ -886,6 +978,50 @@ out_krealloc:
> > }
> >
> > /*
> > + * Map efi regions which was passed via setup_data. The virt_addr is a fixed
> > + * addr which was used in first kernel in case kexec boot.
> > + */
> > +static int __init map_regions_fixed(void)
> > +{
> > + int i, s, ret = 0;
> > + u64 end, systab;
> > + unsigned long size;
> > + efi_memory_desc_t *md;
> > + struct efi_setup_data *data;
> > +
> > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > + data = early_memremap(efi_setup, s);
> > + if (!data) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > + efi_map_region_fixed(md); /* FIXME: add error handling */
>
> Oops. Please fix this ;-)
Have discussed this with Boris, he will take care of this after he added
error handling in his __map_region function.
--
Thanks for review
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 2:10 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:10 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59, linux-efi, toshi.kani, greg, x86, kexec, linux-kernel,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
On 12/11/13 at 12:13pm, Matt Fleming wrote:
> On Mon, 09 Dec, at 05:42:22PM, Dave Young wrote:
> > Add a new setup_data type SETUP_EFI for kexec use.
> > Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
> >
> > When entering virtual mode, directly mapping the efi runtime ragions which
> > we passed in previously. And skip the step to call SetVirtualAddressMap.
> >
> > Specially for HP z420 workstation we need save the smbios physical address.
> > The kernel boot sequence proceeds in the following order. Step 2
> > requires efi.smbios to be the physical address. However, I found that on
> > HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
> > we need set it back to the physical address with the smbios in
> > efi_setup_data. (When it is still the physical address, it simply sets
> > the same value.)
> >
> > 1. efi_init() - Set efi.smbios from EFI system table
> > 2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
> > 3. efi_enter_virtual_mode() - Map EFI ranges
> >
> > Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
> > HP z420 workstation.
> >
> > v2: refresh based on previous patch changes, code cleanup.
> > v3: use ioremap instead of phys_to_virt for efi_setup
> > v5: improve some code structure per comments from Matt
> > Boris: improve code structure, spell fix, etc.
> > Improve changelog from Toshi.
> > change the variable efi_setup to the physical address of efi setup_data
> > instead of the ioremapped virt address
> >
> > Signed-off-by: Dave Young <dyoung@redhat.com>
> > ---
> > arch/x86/include/asm/efi.h | 11 ++
> > arch/x86/include/uapi/asm/bootparam.h | 1 +
> > arch/x86/kernel/setup.c | 3 +
> > arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
> > 4 files changed, 187 insertions(+), 23 deletions(-)
>
> [...]
>
> > @@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
> > }
> > early_param("efi_no_storage_paranoia", setup_storage_paranoia);
> >
> > +void __init parse_efi_setup(u64 phys_addr)
> > +{
> > + struct setup_data *sd;
> > +
> > + if (!efi_enabled(EFI_64BIT)) {
> > + pr_warn("SETUP_EFI not supported on 32-bit\n");
> > + return;
> > + }
> > +
> > + sd = early_memremap(phys_addr, sizeof(struct setup_data));
> > + if (!sd) {
> > + pr_warn("efi: early_memremap setup_data failed\n");
>
> You shouldn't need the "efi:" prefix in the message.
Hmm, remove efi: looks better, will update.
>
> > @@ -676,6 +766,8 @@ void __init efi_init(void)
> > efi.systab->hdr.revision >> 16,
> > efi.systab->hdr.revision & 0xffff, vendor);
> >
> > + efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
> > +
>
> Please check the return value.
I missed this one, will update.
>
> > if (efi_config_init(arch_tables))
> > return;
> >
> > @@ -886,6 +978,50 @@ out_krealloc:
> > }
> >
> > /*
> > + * Map efi regions which was passed via setup_data. The virt_addr is a fixed
> > + * addr which was used in first kernel in case kexec boot.
> > + */
> > +static int __init map_regions_fixed(void)
> > +{
> > + int i, s, ret = 0;
> > + u64 end, systab;
> > + unsigned long size;
> > + efi_memory_desc_t *md;
> > + struct efi_setup_data *data;
> > +
> > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > + data = early_memremap(efi_setup, s);
> > + if (!data) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > + efi_map_region_fixed(md); /* FIXME: add error handling */
>
> Oops. Please fix this ;-)
Have discussed this with Boris, he will take care of this after he added
error handling in his __map_region function.
--
Thanks for review
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 2:10 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 2:10 UTC (permalink / raw)
To: Matt Fleming
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, greg-U8xfFu+wG4EAvxtiuMwx3w,
x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On 12/11/13 at 12:13pm, Matt Fleming wrote:
> On Mon, 09 Dec, at 05:42:22PM, Dave Young wrote:
> > Add a new setup_data type SETUP_EFI for kexec use.
> > Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
> >
> > When entering virtual mode, directly mapping the efi runtime ragions which
> > we passed in previously. And skip the step to call SetVirtualAddressMap.
> >
> > Specially for HP z420 workstation we need save the smbios physical address.
> > The kernel boot sequence proceeds in the following order. Step 2
> > requires efi.smbios to be the physical address. However, I found that on
> > HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
> > we need set it back to the physical address with the smbios in
> > efi_setup_data. (When it is still the physical address, it simply sets
> > the same value.)
> >
> > 1. efi_init() - Set efi.smbios from EFI system table
> > 2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
> > 3. efi_enter_virtual_mode() - Map EFI ranges
> >
> > Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
> > HP z420 workstation.
> >
> > v2: refresh based on previous patch changes, code cleanup.
> > v3: use ioremap instead of phys_to_virt for efi_setup
> > v5: improve some code structure per comments from Matt
> > Boris: improve code structure, spell fix, etc.
> > Improve changelog from Toshi.
> > change the variable efi_setup to the physical address of efi setup_data
> > instead of the ioremapped virt address
> >
> > Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > ---
> > arch/x86/include/asm/efi.h | 11 ++
> > arch/x86/include/uapi/asm/bootparam.h | 1 +
> > arch/x86/kernel/setup.c | 3 +
> > arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
> > 4 files changed, 187 insertions(+), 23 deletions(-)
>
> [...]
>
> > @@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
> > }
> > early_param("efi_no_storage_paranoia", setup_storage_paranoia);
> >
> > +void __init parse_efi_setup(u64 phys_addr)
> > +{
> > + struct setup_data *sd;
> > +
> > + if (!efi_enabled(EFI_64BIT)) {
> > + pr_warn("SETUP_EFI not supported on 32-bit\n");
> > + return;
> > + }
> > +
> > + sd = early_memremap(phys_addr, sizeof(struct setup_data));
> > + if (!sd) {
> > + pr_warn("efi: early_memremap setup_data failed\n");
>
> You shouldn't need the "efi:" prefix in the message.
Hmm, remove efi: looks better, will update.
>
> > @@ -676,6 +766,8 @@ void __init efi_init(void)
> > efi.systab->hdr.revision >> 16,
> > efi.systab->hdr.revision & 0xffff, vendor);
> >
> > + efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
> > +
>
> Please check the return value.
I missed this one, will update.
>
> > if (efi_config_init(arch_tables))
> > return;
> >
> > @@ -886,6 +978,50 @@ out_krealloc:
> > }
> >
> > /*
> > + * Map efi regions which was passed via setup_data. The virt_addr is a fixed
> > + * addr which was used in first kernel in case kexec boot.
> > + */
> > +static int __init map_regions_fixed(void)
> > +{
> > + int i, s, ret = 0;
> > + u64 end, systab;
> > + unsigned long size;
> > + efi_memory_desc_t *md;
> > + struct efi_setup_data *data;
> > +
> > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > + data = early_memremap(efi_setup, s);
> > + if (!data) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > + efi_map_region_fixed(md); /* FIXME: add error handling */
>
> Oops. Please fix this ;-)
Have discussed this with Boris, he will take care of this after he added
error handling in his __map_region function.
--
Thanks for review
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-11 22:20 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 22:20 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On Mon, Dec 09, 2013 at 05:42:22PM +0800, Dave Young wrote:
> Add a new setup_data type SETUP_EFI for kexec use.
> Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
>
> When entering virtual mode, directly mapping the efi runtime ragions which
> we passed in previously. And skip the step to call SetVirtualAddressMap.
>
> Specially for HP z420 workstation we need save the smbios physical address.
> The kernel boot sequence proceeds in the following order. Step 2
> requires efi.smbios to be the physical address. However, I found that on
> HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
> we need set it back to the physical address with the smbios in
> efi_setup_data. (When it is still the physical address, it simply sets
> the same value.)
>
> 1. efi_init() - Set efi.smbios from EFI system table
> 2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
> 3. efi_enter_virtual_mode() - Map EFI ranges
>
> Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
> HP z420 workstation.
>
> v2: refresh based on previous patch changes, code cleanup.
> v3: use ioremap instead of phys_to_virt for efi_setup
> v5: improve some code structure per comments from Matt
> Boris: improve code structure, spell fix, etc.
> Improve changelog from Toshi.
> change the variable efi_setup to the physical address of efi setup_data
> instead of the ioremapped virt address
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/include/asm/efi.h | 11 ++
> arch/x86/include/uapi/asm/bootparam.h | 1 +
> arch/x86/kernel/setup.c | 3 +
> arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
> 4 files changed, 187 insertions(+), 23 deletions(-)
...
> @@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
> }
> early_param("efi_no_storage_paranoia", setup_storage_paranoia);
>
> +void __init parse_efi_setup(u64 phys_addr)
> +{
> + struct setup_data *sd;
> +
> + if (!efi_enabled(EFI_64BIT)) {
> + pr_warn("SETUP_EFI not supported on 32-bit\n");
> + return;
> + }
Shouldn't this function be in two versions in efi_64.c and efi_32.c?
This way you don't need this check with cryptic printk message.
> +
> + sd = early_memremap(phys_addr, sizeof(struct setup_data));
> + if (!sd) {
> + pr_warn("efi: early_memremap setup_data failed\n");
> + return;
> + }
> + efi_setup = phys_addr + sizeof(struct setup_data);
> + nr_efi_runtime_map = (sd->len - sizeof(struct efi_setup_data)) /
> + sizeof(efi_memory_desc_t);
> + early_memunmap(sd, sizeof(struct setup_data));
> +}
>
> static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
> {
> @@ -494,18 +514,28 @@ static int __init efi_systab_init(void *phys)
> {
> if (efi_enabled(EFI_64BIT)) {
> efi_system_table_64_t *systab64;
> + struct efi_setup_data *data = NULL;
> u64 tmp = 0;
>
> + if (efi_setup) {
> + data = early_memremap(efi_setup, sizeof(*data));
> + if (!data)
> + return -ENOMEM;
> + }
> systab64 = early_memremap((unsigned long)phys,
> sizeof(*systab64));
> if (systab64 == NULL) {
> pr_err("Couldn't map the system table!\n");
> + if (data)
> + early_memunmap(data, sizeof(*data));
> return -ENOMEM;
> }
>
> efi_systab.hdr = systab64->hdr;
> - efi_systab.fw_vendor = systab64->fw_vendor;
> - tmp |= systab64->fw_vendor;
> +
> + efi_systab.fw_vendor = data ? (unsigned long)data->fw_vendor :
> + systab64->fw_vendor;
> + tmp |= efi_systab.fw_vendor;
> efi_systab.fw_revision = systab64->fw_revision;
> efi_systab.con_in_handle = systab64->con_in_handle;
> tmp |= systab64->con_in_handle;
> @@ -519,15 +549,20 @@ static int __init efi_systab_init(void *phys)
> tmp |= systab64->stderr_handle;
> efi_systab.stderr = systab64->stderr;
> tmp |= systab64->stderr;
> - efi_systab.runtime = (void *)(unsigned long)systab64->runtime;
> - tmp |= systab64->runtime;
> + efi_systab.runtime = data ?
> + (void *)(unsigned long)data->runtime :
> + (void *)(unsigned long)systab64->runtime;
> + tmp |= (unsigned long)efi_systab.runtime;
> efi_systab.boottime = (void *)(unsigned long)systab64->boottime;
> tmp |= systab64->boottime;
> efi_systab.nr_tables = systab64->nr_tables;
> - efi_systab.tables = systab64->tables;
> - tmp |= systab64->tables;
> + efi_systab.tables = data ? (unsigned long)data->tables :
> + systab64->tables;
> + tmp |= efi_systab.tables;
>
> early_memunmap(systab64, sizeof(*systab64));
> + if (data)
> + early_memunmap(data, sizeof(*data));
> #ifdef CONFIG_X86_32
> if (tmp >> 32) {
> pr_err("EFI data located above 4GB, disabling EFI.\n");
> @@ -631,6 +666,61 @@ static int __init efi_memmap_init(void)
> return 0;
> }
>
> +/*
> + * For kexec kernel there's some special config table entries which could be
> + * converted to virtual addresses after entering virtual mode. In kexec kernel
> + * we need the physical addresses instead, thus passing them via setup_data
> + * and update the entries to physical addresses in this function.
Rewrite:
"A number of config table entries get remapped to virtual addresses
after entering EFI virtual mode. However, the kexec kernel requires
their physical addresses therefore we pass them via setup_data and
correct those entries to their respective physical addresses here."
> + *
> + * Currently only handles smbios which is necessary for HP z420.
Didn't we say that this behavior is coming from a generic UEFI fw
implementation and if so, no need to mention z420?
> + */
> +static int __init efi_reuse_config(u64 tables, int nr_tables)
> +{
> + int i, sz, ret = 0;
> + void *p, *tablep;
> + struct efi_setup_data *data;
> +
> + if (!efi_setup)
> + return 0;
> +
> + if (!efi_enabled(EFI_64BIT))
> + return 0;
> +
> + data = early_memremap(efi_setup, sizeof(*data));
> + if (!data) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + if (!data->smbios)
> + goto out_memremap;
> +
> + sz = sizeof(efi_config_table_64_t);
> +
> + p = tablep = early_memremap(tables, nr_tables * sz);
> + if (!p) {
> + pr_err("Could not map Configuration table!\n");
> + ret = -ENOMEM;
> + goto out_memremap;
> + }
> +
> + for (i = 0; i < efi.systab->nr_tables; i++) {
> + efi_guid_t guid;
> +
> + guid = ((efi_config_table_64_t *)p)->guid;
> +
> + if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
> + ((efi_config_table_64_t *)p)->table = data->smbios;
> + p += sz;
> + }
> + early_memunmap(tablep, nr_tables * sz);
> +
> +out_memremap:
> + early_memunmap(data, sizeof(*data));
> +out:
> + return ret;
> +}
> +
> void __init efi_init(void)
> {
> efi_char16_t *c16;
> @@ -676,6 +766,8 @@ void __init efi_init(void)
> efi.systab->hdr.revision >> 16,
> efi.systab->hdr.revision & 0xffff, vendor);
>
> + efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
> +
> if (efi_config_init(arch_tables))
> return;
>
> @@ -886,6 +978,50 @@ out_krealloc:
> }
>
> /*
> + * Map efi regions which was passed via setup_data. The virt_addr is a fixed
were
> + * addr which was used in first kernel in case kexec boot.
^
of a
> + */
> +static int __init map_regions_fixed(void)
> +{
> + int i, s, ret = 0;
> + u64 end, systab;
> + unsigned long size;
> + efi_memory_desc_t *md;
> + struct efi_setup_data *data;
> +
> + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> + data = early_memremap(efi_setup, s);
> + if (!data) {
> + ret = -ENOMEM;
> + goto out;
> + }
newline.
> + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> + efi_map_region_fixed(md); /* FIXME: add error handling */
> + size = md->num_pages << PAGE_SHIFT;
> + end = md->phys_addr + size;
> +
> + systab = (u64) (unsigned long) efi_phys.systab;
> + if (md->phys_addr <= systab && systab < end) {
> + systab += md->virt_addr - md->phys_addr;
> + efi.systab = (efi_system_table_t *)(unsigned long)systab;
> + }
> + ret = save_runtime_map(md, i);
Wait a minute, this is executed in the second, kexec-ed kernel, right?
Why do we need to save the map there too?
> + if (ret)
> + goto out_save_runtime;
> + }
> +
> + early_memunmap(data, s);
> + return 0;
> +
> +out_save_runtime:
> + kfree(efi_runtime_map);
> + nr_efi_runtime_map = 0;
> + early_memunmap(data, s);
> +out:
> + return ret;
> +}
> +
> +/*
> * This function will switch the EFI runtime services to virtual mode.
> * Essentially, we look through the EFI memmap and map every region that
> * has the runtime attribute bit set in its memory descriptor into the
> @@ -901,12 +1037,16 @@ out_krealloc:
> * so that we're in a different address space when calling a runtime
> * function. For function arguments passing we do copy the PGDs of the
> * kernel page table into ->trampoline_pgd prior to each call.
> + *
> + * Specially for kexec boot, efi runtime maps in previous kernel should
> + * be passed in via setup_data. In that case runtime ranges will be mapped
> + * to the same virtual addresses exactly same as the ones in previous kernel.
"... to the same ..exactly same as ... " sounds funny. What's wrong with
"... to the same virtual addresses as the first kernel."
or if you really insist on "exact":
"... to the same exact virtual addresses as the first kernel."
> */
> void __init efi_enter_virtual_mode(void)
> {
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-11 22:20 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 22:20 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On Mon, Dec 09, 2013 at 05:42:22PM +0800, Dave Young wrote:
> Add a new setup_data type SETUP_EFI for kexec use.
> Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
>
> When entering virtual mode, directly mapping the efi runtime ragions which
> we passed in previously. And skip the step to call SetVirtualAddressMap.
>
> Specially for HP z420 workstation we need save the smbios physical address.
> The kernel boot sequence proceeds in the following order. Step 2
> requires efi.smbios to be the physical address. However, I found that on
> HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
> we need set it back to the physical address with the smbios in
> efi_setup_data. (When it is still the physical address, it simply sets
> the same value.)
>
> 1. efi_init() - Set efi.smbios from EFI system table
> 2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
> 3. efi_enter_virtual_mode() - Map EFI ranges
>
> Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
> HP z420 workstation.
>
> v2: refresh based on previous patch changes, code cleanup.
> v3: use ioremap instead of phys_to_virt for efi_setup
> v5: improve some code structure per comments from Matt
> Boris: improve code structure, spell fix, etc.
> Improve changelog from Toshi.
> change the variable efi_setup to the physical address of efi setup_data
> instead of the ioremapped virt address
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/include/asm/efi.h | 11 ++
> arch/x86/include/uapi/asm/bootparam.h | 1 +
> arch/x86/kernel/setup.c | 3 +
> arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
> 4 files changed, 187 insertions(+), 23 deletions(-)
...
> @@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
> }
> early_param("efi_no_storage_paranoia", setup_storage_paranoia);
>
> +void __init parse_efi_setup(u64 phys_addr)
> +{
> + struct setup_data *sd;
> +
> + if (!efi_enabled(EFI_64BIT)) {
> + pr_warn("SETUP_EFI not supported on 32-bit\n");
> + return;
> + }
Shouldn't this function be in two versions in efi_64.c and efi_32.c?
This way you don't need this check with cryptic printk message.
> +
> + sd = early_memremap(phys_addr, sizeof(struct setup_data));
> + if (!sd) {
> + pr_warn("efi: early_memremap setup_data failed\n");
> + return;
> + }
> + efi_setup = phys_addr + sizeof(struct setup_data);
> + nr_efi_runtime_map = (sd->len - sizeof(struct efi_setup_data)) /
> + sizeof(efi_memory_desc_t);
> + early_memunmap(sd, sizeof(struct setup_data));
> +}
>
> static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
> {
> @@ -494,18 +514,28 @@ static int __init efi_systab_init(void *phys)
> {
> if (efi_enabled(EFI_64BIT)) {
> efi_system_table_64_t *systab64;
> + struct efi_setup_data *data = NULL;
> u64 tmp = 0;
>
> + if (efi_setup) {
> + data = early_memremap(efi_setup, sizeof(*data));
> + if (!data)
> + return -ENOMEM;
> + }
> systab64 = early_memremap((unsigned long)phys,
> sizeof(*systab64));
> if (systab64 == NULL) {
> pr_err("Couldn't map the system table!\n");
> + if (data)
> + early_memunmap(data, sizeof(*data));
> return -ENOMEM;
> }
>
> efi_systab.hdr = systab64->hdr;
> - efi_systab.fw_vendor = systab64->fw_vendor;
> - tmp |= systab64->fw_vendor;
> +
> + efi_systab.fw_vendor = data ? (unsigned long)data->fw_vendor :
> + systab64->fw_vendor;
> + tmp |= efi_systab.fw_vendor;
> efi_systab.fw_revision = systab64->fw_revision;
> efi_systab.con_in_handle = systab64->con_in_handle;
> tmp |= systab64->con_in_handle;
> @@ -519,15 +549,20 @@ static int __init efi_systab_init(void *phys)
> tmp |= systab64->stderr_handle;
> efi_systab.stderr = systab64->stderr;
> tmp |= systab64->stderr;
> - efi_systab.runtime = (void *)(unsigned long)systab64->runtime;
> - tmp |= systab64->runtime;
> + efi_systab.runtime = data ?
> + (void *)(unsigned long)data->runtime :
> + (void *)(unsigned long)systab64->runtime;
> + tmp |= (unsigned long)efi_systab.runtime;
> efi_systab.boottime = (void *)(unsigned long)systab64->boottime;
> tmp |= systab64->boottime;
> efi_systab.nr_tables = systab64->nr_tables;
> - efi_systab.tables = systab64->tables;
> - tmp |= systab64->tables;
> + efi_systab.tables = data ? (unsigned long)data->tables :
> + systab64->tables;
> + tmp |= efi_systab.tables;
>
> early_memunmap(systab64, sizeof(*systab64));
> + if (data)
> + early_memunmap(data, sizeof(*data));
> #ifdef CONFIG_X86_32
> if (tmp >> 32) {
> pr_err("EFI data located above 4GB, disabling EFI.\n");
> @@ -631,6 +666,61 @@ static int __init efi_memmap_init(void)
> return 0;
> }
>
> +/*
> + * For kexec kernel there's some special config table entries which could be
> + * converted to virtual addresses after entering virtual mode. In kexec kernel
> + * we need the physical addresses instead, thus passing them via setup_data
> + * and update the entries to physical addresses in this function.
Rewrite:
"A number of config table entries get remapped to virtual addresses
after entering EFI virtual mode. However, the kexec kernel requires
their physical addresses therefore we pass them via setup_data and
correct those entries to their respective physical addresses here."
> + *
> + * Currently only handles smbios which is necessary for HP z420.
Didn't we say that this behavior is coming from a generic UEFI fw
implementation and if so, no need to mention z420?
> + */
> +static int __init efi_reuse_config(u64 tables, int nr_tables)
> +{
> + int i, sz, ret = 0;
> + void *p, *tablep;
> + struct efi_setup_data *data;
> +
> + if (!efi_setup)
> + return 0;
> +
> + if (!efi_enabled(EFI_64BIT))
> + return 0;
> +
> + data = early_memremap(efi_setup, sizeof(*data));
> + if (!data) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + if (!data->smbios)
> + goto out_memremap;
> +
> + sz = sizeof(efi_config_table_64_t);
> +
> + p = tablep = early_memremap(tables, nr_tables * sz);
> + if (!p) {
> + pr_err("Could not map Configuration table!\n");
> + ret = -ENOMEM;
> + goto out_memremap;
> + }
> +
> + for (i = 0; i < efi.systab->nr_tables; i++) {
> + efi_guid_t guid;
> +
> + guid = ((efi_config_table_64_t *)p)->guid;
> +
> + if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
> + ((efi_config_table_64_t *)p)->table = data->smbios;
> + p += sz;
> + }
> + early_memunmap(tablep, nr_tables * sz);
> +
> +out_memremap:
> + early_memunmap(data, sizeof(*data));
> +out:
> + return ret;
> +}
> +
> void __init efi_init(void)
> {
> efi_char16_t *c16;
> @@ -676,6 +766,8 @@ void __init efi_init(void)
> efi.systab->hdr.revision >> 16,
> efi.systab->hdr.revision & 0xffff, vendor);
>
> + efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
> +
> if (efi_config_init(arch_tables))
> return;
>
> @@ -886,6 +978,50 @@ out_krealloc:
> }
>
> /*
> + * Map efi regions which was passed via setup_data. The virt_addr is a fixed
were
> + * addr which was used in first kernel in case kexec boot.
^
of a
> + */
> +static int __init map_regions_fixed(void)
> +{
> + int i, s, ret = 0;
> + u64 end, systab;
> + unsigned long size;
> + efi_memory_desc_t *md;
> + struct efi_setup_data *data;
> +
> + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> + data = early_memremap(efi_setup, s);
> + if (!data) {
> + ret = -ENOMEM;
> + goto out;
> + }
newline.
> + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> + efi_map_region_fixed(md); /* FIXME: add error handling */
> + size = md->num_pages << PAGE_SHIFT;
> + end = md->phys_addr + size;
> +
> + systab = (u64) (unsigned long) efi_phys.systab;
> + if (md->phys_addr <= systab && systab < end) {
> + systab += md->virt_addr - md->phys_addr;
> + efi.systab = (efi_system_table_t *)(unsigned long)systab;
> + }
> + ret = save_runtime_map(md, i);
Wait a minute, this is executed in the second, kexec-ed kernel, right?
Why do we need to save the map there too?
> + if (ret)
> + goto out_save_runtime;
> + }
> +
> + early_memunmap(data, s);
> + return 0;
> +
> +out_save_runtime:
> + kfree(efi_runtime_map);
> + nr_efi_runtime_map = 0;
> + early_memunmap(data, s);
> +out:
> + return ret;
> +}
> +
> +/*
> * This function will switch the EFI runtime services to virtual mode.
> * Essentially, we look through the EFI memmap and map every region that
> * has the runtime attribute bit set in its memory descriptor into the
> @@ -901,12 +1037,16 @@ out_krealloc:
> * so that we're in a different address space when calling a runtime
> * function. For function arguments passing we do copy the PGDs of the
> * kernel page table into ->trampoline_pgd prior to each call.
> + *
> + * Specially for kexec boot, efi runtime maps in previous kernel should
> + * be passed in via setup_data. In that case runtime ranges will be mapped
> + * to the same virtual addresses exactly same as the ones in previous kernel.
"... to the same ..exactly same as ... " sounds funny. What's wrong with
"... to the same virtual addresses as the first kernel."
or if you really insist on "exact":
"... to the same exact virtual addresses as the first kernel."
> */
> void __init efi_enter_virtual_mode(void)
> {
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-11 22:20 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-11 22:20 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On Mon, Dec 09, 2013 at 05:42:22PM +0800, Dave Young wrote:
> Add a new setup_data type SETUP_EFI for kexec use.
> Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
>
> When entering virtual mode, directly mapping the efi runtime ragions which
> we passed in previously. And skip the step to call SetVirtualAddressMap.
>
> Specially for HP z420 workstation we need save the smbios physical address.
> The kernel boot sequence proceeds in the following order. Step 2
> requires efi.smbios to be the physical address. However, I found that on
> HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
> we need set it back to the physical address with the smbios in
> efi_setup_data. (When it is still the physical address, it simply sets
> the same value.)
>
> 1. efi_init() - Set efi.smbios from EFI system table
> 2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
> 3. efi_enter_virtual_mode() - Map EFI ranges
>
> Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
> HP z420 workstation.
>
> v2: refresh based on previous patch changes, code cleanup.
> v3: use ioremap instead of phys_to_virt for efi_setup
> v5: improve some code structure per comments from Matt
> Boris: improve code structure, spell fix, etc.
> Improve changelog from Toshi.
> change the variable efi_setup to the physical address of efi setup_data
> instead of the ioremapped virt address
>
> Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> arch/x86/include/asm/efi.h | 11 ++
> arch/x86/include/uapi/asm/bootparam.h | 1 +
> arch/x86/kernel/setup.c | 3 +
> arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
> 4 files changed, 187 insertions(+), 23 deletions(-)
...
> @@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
> }
> early_param("efi_no_storage_paranoia", setup_storage_paranoia);
>
> +void __init parse_efi_setup(u64 phys_addr)
> +{
> + struct setup_data *sd;
> +
> + if (!efi_enabled(EFI_64BIT)) {
> + pr_warn("SETUP_EFI not supported on 32-bit\n");
> + return;
> + }
Shouldn't this function be in two versions in efi_64.c and efi_32.c?
This way you don't need this check with cryptic printk message.
> +
> + sd = early_memremap(phys_addr, sizeof(struct setup_data));
> + if (!sd) {
> + pr_warn("efi: early_memremap setup_data failed\n");
> + return;
> + }
> + efi_setup = phys_addr + sizeof(struct setup_data);
> + nr_efi_runtime_map = (sd->len - sizeof(struct efi_setup_data)) /
> + sizeof(efi_memory_desc_t);
> + early_memunmap(sd, sizeof(struct setup_data));
> +}
>
> static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
> {
> @@ -494,18 +514,28 @@ static int __init efi_systab_init(void *phys)
> {
> if (efi_enabled(EFI_64BIT)) {
> efi_system_table_64_t *systab64;
> + struct efi_setup_data *data = NULL;
> u64 tmp = 0;
>
> + if (efi_setup) {
> + data = early_memremap(efi_setup, sizeof(*data));
> + if (!data)
> + return -ENOMEM;
> + }
> systab64 = early_memremap((unsigned long)phys,
> sizeof(*systab64));
> if (systab64 == NULL) {
> pr_err("Couldn't map the system table!\n");
> + if (data)
> + early_memunmap(data, sizeof(*data));
> return -ENOMEM;
> }
>
> efi_systab.hdr = systab64->hdr;
> - efi_systab.fw_vendor = systab64->fw_vendor;
> - tmp |= systab64->fw_vendor;
> +
> + efi_systab.fw_vendor = data ? (unsigned long)data->fw_vendor :
> + systab64->fw_vendor;
> + tmp |= efi_systab.fw_vendor;
> efi_systab.fw_revision = systab64->fw_revision;
> efi_systab.con_in_handle = systab64->con_in_handle;
> tmp |= systab64->con_in_handle;
> @@ -519,15 +549,20 @@ static int __init efi_systab_init(void *phys)
> tmp |= systab64->stderr_handle;
> efi_systab.stderr = systab64->stderr;
> tmp |= systab64->stderr;
> - efi_systab.runtime = (void *)(unsigned long)systab64->runtime;
> - tmp |= systab64->runtime;
> + efi_systab.runtime = data ?
> + (void *)(unsigned long)data->runtime :
> + (void *)(unsigned long)systab64->runtime;
> + tmp |= (unsigned long)efi_systab.runtime;
> efi_systab.boottime = (void *)(unsigned long)systab64->boottime;
> tmp |= systab64->boottime;
> efi_systab.nr_tables = systab64->nr_tables;
> - efi_systab.tables = systab64->tables;
> - tmp |= systab64->tables;
> + efi_systab.tables = data ? (unsigned long)data->tables :
> + systab64->tables;
> + tmp |= efi_systab.tables;
>
> early_memunmap(systab64, sizeof(*systab64));
> + if (data)
> + early_memunmap(data, sizeof(*data));
> #ifdef CONFIG_X86_32
> if (tmp >> 32) {
> pr_err("EFI data located above 4GB, disabling EFI.\n");
> @@ -631,6 +666,61 @@ static int __init efi_memmap_init(void)
> return 0;
> }
>
> +/*
> + * For kexec kernel there's some special config table entries which could be
> + * converted to virtual addresses after entering virtual mode. In kexec kernel
> + * we need the physical addresses instead, thus passing them via setup_data
> + * and update the entries to physical addresses in this function.
Rewrite:
"A number of config table entries get remapped to virtual addresses
after entering EFI virtual mode. However, the kexec kernel requires
their physical addresses therefore we pass them via setup_data and
correct those entries to their respective physical addresses here."
> + *
> + * Currently only handles smbios which is necessary for HP z420.
Didn't we say that this behavior is coming from a generic UEFI fw
implementation and if so, no need to mention z420?
> + */
> +static int __init efi_reuse_config(u64 tables, int nr_tables)
> +{
> + int i, sz, ret = 0;
> + void *p, *tablep;
> + struct efi_setup_data *data;
> +
> + if (!efi_setup)
> + return 0;
> +
> + if (!efi_enabled(EFI_64BIT))
> + return 0;
> +
> + data = early_memremap(efi_setup, sizeof(*data));
> + if (!data) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + if (!data->smbios)
> + goto out_memremap;
> +
> + sz = sizeof(efi_config_table_64_t);
> +
> + p = tablep = early_memremap(tables, nr_tables * sz);
> + if (!p) {
> + pr_err("Could not map Configuration table!\n");
> + ret = -ENOMEM;
> + goto out_memremap;
> + }
> +
> + for (i = 0; i < efi.systab->nr_tables; i++) {
> + efi_guid_t guid;
> +
> + guid = ((efi_config_table_64_t *)p)->guid;
> +
> + if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
> + ((efi_config_table_64_t *)p)->table = data->smbios;
> + p += sz;
> + }
> + early_memunmap(tablep, nr_tables * sz);
> +
> +out_memremap:
> + early_memunmap(data, sizeof(*data));
> +out:
> + return ret;
> +}
> +
> void __init efi_init(void)
> {
> efi_char16_t *c16;
> @@ -676,6 +766,8 @@ void __init efi_init(void)
> efi.systab->hdr.revision >> 16,
> efi.systab->hdr.revision & 0xffff, vendor);
>
> + efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
> +
> if (efi_config_init(arch_tables))
> return;
>
> @@ -886,6 +978,50 @@ out_krealloc:
> }
>
> /*
> + * Map efi regions which was passed via setup_data. The virt_addr is a fixed
were
> + * addr which was used in first kernel in case kexec boot.
^
of a
> + */
> +static int __init map_regions_fixed(void)
> +{
> + int i, s, ret = 0;
> + u64 end, systab;
> + unsigned long size;
> + efi_memory_desc_t *md;
> + struct efi_setup_data *data;
> +
> + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> + data = early_memremap(efi_setup, s);
> + if (!data) {
> + ret = -ENOMEM;
> + goto out;
> + }
newline.
> + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> + efi_map_region_fixed(md); /* FIXME: add error handling */
> + size = md->num_pages << PAGE_SHIFT;
> + end = md->phys_addr + size;
> +
> + systab = (u64) (unsigned long) efi_phys.systab;
> + if (md->phys_addr <= systab && systab < end) {
> + systab += md->virt_addr - md->phys_addr;
> + efi.systab = (efi_system_table_t *)(unsigned long)systab;
> + }
> + ret = save_runtime_map(md, i);
Wait a minute, this is executed in the second, kexec-ed kernel, right?
Why do we need to save the map there too?
> + if (ret)
> + goto out_save_runtime;
> + }
> +
> + early_memunmap(data, s);
> + return 0;
> +
> +out_save_runtime:
> + kfree(efi_runtime_map);
> + nr_efi_runtime_map = 0;
> + early_memunmap(data, s);
> +out:
> + return ret;
> +}
> +
> +/*
> * This function will switch the EFI runtime services to virtual mode.
> * Essentially, we look through the EFI memmap and map every region that
> * has the runtime attribute bit set in its memory descriptor into the
> @@ -901,12 +1037,16 @@ out_krealloc:
> * so that we're in a different address space when calling a runtime
> * function. For function arguments passing we do copy the PGDs of the
> * kernel page table into ->trampoline_pgd prior to each call.
> + *
> + * Specially for kexec boot, efi runtime maps in previous kernel should
> + * be passed in via setup_data. In that case runtime ranges will be mapped
> + * to the same virtual addresses exactly same as the ones in previous kernel.
"... to the same ..exactly same as ... " sounds funny. What's wrong with
"... to the same virtual addresses as the first kernel."
or if you really insist on "exact":
"... to the same exact virtual addresses as the first kernel."
> */
> void __init efi_enter_virtual_mode(void)
> {
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 3:06 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 3:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On 12/11/13 at 11:20pm, Borislav Petkov wrote:
> On Mon, Dec 09, 2013 at 05:42:22PM +0800, Dave Young wrote:
> > Add a new setup_data type SETUP_EFI for kexec use.
> > Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
> >
> > When entering virtual mode, directly mapping the efi runtime ragions which
> > we passed in previously. And skip the step to call SetVirtualAddressMap.
> >
> > Specially for HP z420 workstation we need save the smbios physical address.
> > The kernel boot sequence proceeds in the following order. Step 2
> > requires efi.smbios to be the physical address. However, I found that on
> > HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
> > we need set it back to the physical address with the smbios in
> > efi_setup_data. (When it is still the physical address, it simply sets
> > the same value.)
> >
> > 1. efi_init() - Set efi.smbios from EFI system table
> > 2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
> > 3. efi_enter_virtual_mode() - Map EFI ranges
> >
> > Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
> > HP z420 workstation.
> >
> > v2: refresh based on previous patch changes, code cleanup.
> > v3: use ioremap instead of phys_to_virt for efi_setup
> > v5: improve some code structure per comments from Matt
> > Boris: improve code structure, spell fix, etc.
> > Improve changelog from Toshi.
> > change the variable efi_setup to the physical address of efi setup_data
> > instead of the ioremapped virt address
> >
> > Signed-off-by: Dave Young <dyoung@redhat.com>
> > ---
> > arch/x86/include/asm/efi.h | 11 ++
> > arch/x86/include/uapi/asm/bootparam.h | 1 +
> > arch/x86/kernel/setup.c | 3 +
> > arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
> > 4 files changed, 187 insertions(+), 23 deletions(-)
>
> ...
>
> > @@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
> > }
> > early_param("efi_no_storage_paranoia", setup_storage_paranoia);
> >
> > +void __init parse_efi_setup(u64 phys_addr)
> > +{
> > + struct setup_data *sd;
> > +
> > + if (!efi_enabled(EFI_64BIT)) {
> > + pr_warn("SETUP_EFI not supported on 32-bit\n");
> > + return;
> > + }
>
> Shouldn't this function be in two versions in efi_64.c and efi_32.c?
> This way you don't need this check with cryptic printk message.
Ok, will update.
>
> > +
> > + sd = early_memremap(phys_addr, sizeof(struct setup_data));
> > + if (!sd) {
> > + pr_warn("efi: early_memremap setup_data failed\n");
> > + return;
> > + }
> > + efi_setup = phys_addr + sizeof(struct setup_data);
> > + nr_efi_runtime_map = (sd->len - sizeof(struct efi_setup_data)) /
> > + sizeof(efi_memory_desc_t);
> > + early_memunmap(sd, sizeof(struct setup_data));
> > +}
> >
> > static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
> > {
> > @@ -494,18 +514,28 @@ static int __init efi_systab_init(void *phys)
> > {
> > if (efi_enabled(EFI_64BIT)) {
> > efi_system_table_64_t *systab64;
> > + struct efi_setup_data *data = NULL;
> > u64 tmp = 0;
> >
> > + if (efi_setup) {
> > + data = early_memremap(efi_setup, sizeof(*data));
> > + if (!data)
> > + return -ENOMEM;
> > + }
> > systab64 = early_memremap((unsigned long)phys,
> > sizeof(*systab64));
> > if (systab64 == NULL) {
> > pr_err("Couldn't map the system table!\n");
> > + if (data)
> > + early_memunmap(data, sizeof(*data));
> > return -ENOMEM;
> > }
> >
> > efi_systab.hdr = systab64->hdr;
> > - efi_systab.fw_vendor = systab64->fw_vendor;
> > - tmp |= systab64->fw_vendor;
> > +
> > + efi_systab.fw_vendor = data ? (unsigned long)data->fw_vendor :
> > + systab64->fw_vendor;
> > + tmp |= efi_systab.fw_vendor;
> > efi_systab.fw_revision = systab64->fw_revision;
> > efi_systab.con_in_handle = systab64->con_in_handle;
> > tmp |= systab64->con_in_handle;
> > @@ -519,15 +549,20 @@ static int __init efi_systab_init(void *phys)
> > tmp |= systab64->stderr_handle;
> > efi_systab.stderr = systab64->stderr;
> > tmp |= systab64->stderr;
> > - efi_systab.runtime = (void *)(unsigned long)systab64->runtime;
> > - tmp |= systab64->runtime;
> > + efi_systab.runtime = data ?
> > + (void *)(unsigned long)data->runtime :
> > + (void *)(unsigned long)systab64->runtime;
> > + tmp |= (unsigned long)efi_systab.runtime;
> > efi_systab.boottime = (void *)(unsigned long)systab64->boottime;
> > tmp |= systab64->boottime;
> > efi_systab.nr_tables = systab64->nr_tables;
> > - efi_systab.tables = systab64->tables;
> > - tmp |= systab64->tables;
> > + efi_systab.tables = data ? (unsigned long)data->tables :
> > + systab64->tables;
> > + tmp |= efi_systab.tables;
> >
> > early_memunmap(systab64, sizeof(*systab64));
> > + if (data)
> > + early_memunmap(data, sizeof(*data));
> > #ifdef CONFIG_X86_32
> > if (tmp >> 32) {
> > pr_err("EFI data located above 4GB, disabling EFI.\n");
> > @@ -631,6 +666,61 @@ static int __init efi_memmap_init(void)
> > return 0;
> > }
> >
> > +/*
> > + * For kexec kernel there's some special config table entries which could be
> > + * converted to virtual addresses after entering virtual mode. In kexec kernel
> > + * we need the physical addresses instead, thus passing them via setup_data
> > + * and update the entries to physical addresses in this function.
>
> Rewrite:
>
> "A number of config table entries get remapped to virtual addresses
> after entering EFI virtual mode. However, the kexec kernel requires
> their physical addresses therefore we pass them via setup_data and
> correct those entries to their respective physical addresses here."
Thanks for the rewriting. Will use.
>
> > + *
> > + * Currently only handles smbios which is necessary for HP z420.
>
> Didn't we say that this behavior is coming from a generic UEFI fw
> implementation and if so, no need to mention z420?
Yes, but till now I only reproduced this on z420 so how about below:
"Currently only handles smbios which is necessary for some firmware
implementation."
It might be general but also might only related to some version of
the general firmware implementation, it's hard to say...
>
> > + */
> > +static int __init efi_reuse_config(u64 tables, int nr_tables)
> > +{
> > + int i, sz, ret = 0;
> > + void *p, *tablep;
> > + struct efi_setup_data *data;
> > +
> > + if (!efi_setup)
> > + return 0;
> > +
> > + if (!efi_enabled(EFI_64BIT))
> > + return 0;
> > +
> > + data = early_memremap(efi_setup, sizeof(*data));
> > + if (!data) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > +
> > + if (!data->smbios)
> > + goto out_memremap;
> > +
> > + sz = sizeof(efi_config_table_64_t);
> > +
> > + p = tablep = early_memremap(tables, nr_tables * sz);
> > + if (!p) {
> > + pr_err("Could not map Configuration table!\n");
> > + ret = -ENOMEM;
> > + goto out_memremap;
> > + }
> > +
> > + for (i = 0; i < efi.systab->nr_tables; i++) {
> > + efi_guid_t guid;
> > +
> > + guid = ((efi_config_table_64_t *)p)->guid;
> > +
> > + if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
> > + ((efi_config_table_64_t *)p)->table = data->smbios;
> > + p += sz;
> > + }
> > + early_memunmap(tablep, nr_tables * sz);
> > +
> > +out_memremap:
> > + early_memunmap(data, sizeof(*data));
> > +out:
> > + return ret;
> > +}
> > +
> > void __init efi_init(void)
> > {
> > efi_char16_t *c16;
> > @@ -676,6 +766,8 @@ void __init efi_init(void)
> > efi.systab->hdr.revision >> 16,
> > efi.systab->hdr.revision & 0xffff, vendor);
> >
> > + efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
> > +
> > if (efi_config_init(arch_tables))
> > return;
> >
> > @@ -886,6 +978,50 @@ out_krealloc:
> > }
> >
> > /*
> > + * Map efi regions which was passed via setup_data. The virt_addr is a fixed
>
> were
Will update
>
> > + * addr which was used in first kernel in case kexec boot.
> ^
> of a
Will update
>
> > + */
> > +static int __init map_regions_fixed(void)
> > +{
> > + int i, s, ret = 0;
> > + u64 end, systab;
> > + unsigned long size;
> > + efi_memory_desc_t *md;
> > + struct efi_setup_data *data;
> > +
> > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > + data = early_memremap(efi_setup, s);
> > + if (!data) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
>
> newline.
Will remove
>
> > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > + efi_map_region_fixed(md); /* FIXME: add error handling */
> > + size = md->num_pages << PAGE_SHIFT;
> > + end = md->phys_addr + size;
> > +
> > + systab = (u64) (unsigned long) efi_phys.systab;
> > + if (md->phys_addr <= systab && systab < end) {
> > + systab += md->virt_addr - md->phys_addr;
> > + efi.systab = (efi_system_table_t *)(unsigned long)systab;
> > + }
> > + ret = save_runtime_map(md, i);
>
> Wait a minute, this is executed in the second, kexec-ed kernel, right?
> Why do we need to save the map there too?
Yes, nested kexec need this.
>
> > + if (ret)
> > + goto out_save_runtime;
> > + }
> > +
> > + early_memunmap(data, s);
> > + return 0;
> > +
> > +out_save_runtime:
> > + kfree(efi_runtime_map);
> > + nr_efi_runtime_map = 0;
> > + early_memunmap(data, s);
> > +out:
> > + return ret;
> > +}
> > +
> > +/*
> > * This function will switch the EFI runtime services to virtual mode.
> > * Essentially, we look through the EFI memmap and map every region that
> > * has the runtime attribute bit set in its memory descriptor into the
> > @@ -901,12 +1037,16 @@ out_krealloc:
> > * so that we're in a different address space when calling a runtime
> > * function. For function arguments passing we do copy the PGDs of the
> > * kernel page table into ->trampoline_pgd prior to each call.
> > + *
> > + * Specially for kexec boot, efi runtime maps in previous kernel should
> > + * be passed in via setup_data. In that case runtime ranges will be mapped
> > + * to the same virtual addresses exactly same as the ones in previous kernel.
>
> "... to the same ..exactly same as ... " sounds funny. What's wrong with
>
> "... to the same virtual addresses as the first kernel."
Will use above one.
--
Thanks for review
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 3:06 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 3:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On 12/11/13 at 11:20pm, Borislav Petkov wrote:
> On Mon, Dec 09, 2013 at 05:42:22PM +0800, Dave Young wrote:
> > Add a new setup_data type SETUP_EFI for kexec use.
> > Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
> >
> > When entering virtual mode, directly mapping the efi runtime ragions which
> > we passed in previously. And skip the step to call SetVirtualAddressMap.
> >
> > Specially for HP z420 workstation we need save the smbios physical address.
> > The kernel boot sequence proceeds in the following order. Step 2
> > requires efi.smbios to be the physical address. However, I found that on
> > HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
> > we need set it back to the physical address with the smbios in
> > efi_setup_data. (When it is still the physical address, it simply sets
> > the same value.)
> >
> > 1. efi_init() - Set efi.smbios from EFI system table
> > 2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
> > 3. efi_enter_virtual_mode() - Map EFI ranges
> >
> > Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
> > HP z420 workstation.
> >
> > v2: refresh based on previous patch changes, code cleanup.
> > v3: use ioremap instead of phys_to_virt for efi_setup
> > v5: improve some code structure per comments from Matt
> > Boris: improve code structure, spell fix, etc.
> > Improve changelog from Toshi.
> > change the variable efi_setup to the physical address of efi setup_data
> > instead of the ioremapped virt address
> >
> > Signed-off-by: Dave Young <dyoung@redhat.com>
> > ---
> > arch/x86/include/asm/efi.h | 11 ++
> > arch/x86/include/uapi/asm/bootparam.h | 1 +
> > arch/x86/kernel/setup.c | 3 +
> > arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
> > 4 files changed, 187 insertions(+), 23 deletions(-)
>
> ...
>
> > @@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
> > }
> > early_param("efi_no_storage_paranoia", setup_storage_paranoia);
> >
> > +void __init parse_efi_setup(u64 phys_addr)
> > +{
> > + struct setup_data *sd;
> > +
> > + if (!efi_enabled(EFI_64BIT)) {
> > + pr_warn("SETUP_EFI not supported on 32-bit\n");
> > + return;
> > + }
>
> Shouldn't this function be in two versions in efi_64.c and efi_32.c?
> This way you don't need this check with cryptic printk message.
Ok, will update.
>
> > +
> > + sd = early_memremap(phys_addr, sizeof(struct setup_data));
> > + if (!sd) {
> > + pr_warn("efi: early_memremap setup_data failed\n");
> > + return;
> > + }
> > + efi_setup = phys_addr + sizeof(struct setup_data);
> > + nr_efi_runtime_map = (sd->len - sizeof(struct efi_setup_data)) /
> > + sizeof(efi_memory_desc_t);
> > + early_memunmap(sd, sizeof(struct setup_data));
> > +}
> >
> > static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
> > {
> > @@ -494,18 +514,28 @@ static int __init efi_systab_init(void *phys)
> > {
> > if (efi_enabled(EFI_64BIT)) {
> > efi_system_table_64_t *systab64;
> > + struct efi_setup_data *data = NULL;
> > u64 tmp = 0;
> >
> > + if (efi_setup) {
> > + data = early_memremap(efi_setup, sizeof(*data));
> > + if (!data)
> > + return -ENOMEM;
> > + }
> > systab64 = early_memremap((unsigned long)phys,
> > sizeof(*systab64));
> > if (systab64 == NULL) {
> > pr_err("Couldn't map the system table!\n");
> > + if (data)
> > + early_memunmap(data, sizeof(*data));
> > return -ENOMEM;
> > }
> >
> > efi_systab.hdr = systab64->hdr;
> > - efi_systab.fw_vendor = systab64->fw_vendor;
> > - tmp |= systab64->fw_vendor;
> > +
> > + efi_systab.fw_vendor = data ? (unsigned long)data->fw_vendor :
> > + systab64->fw_vendor;
> > + tmp |= efi_systab.fw_vendor;
> > efi_systab.fw_revision = systab64->fw_revision;
> > efi_systab.con_in_handle = systab64->con_in_handle;
> > tmp |= systab64->con_in_handle;
> > @@ -519,15 +549,20 @@ static int __init efi_systab_init(void *phys)
> > tmp |= systab64->stderr_handle;
> > efi_systab.stderr = systab64->stderr;
> > tmp |= systab64->stderr;
> > - efi_systab.runtime = (void *)(unsigned long)systab64->runtime;
> > - tmp |= systab64->runtime;
> > + efi_systab.runtime = data ?
> > + (void *)(unsigned long)data->runtime :
> > + (void *)(unsigned long)systab64->runtime;
> > + tmp |= (unsigned long)efi_systab.runtime;
> > efi_systab.boottime = (void *)(unsigned long)systab64->boottime;
> > tmp |= systab64->boottime;
> > efi_systab.nr_tables = systab64->nr_tables;
> > - efi_systab.tables = systab64->tables;
> > - tmp |= systab64->tables;
> > + efi_systab.tables = data ? (unsigned long)data->tables :
> > + systab64->tables;
> > + tmp |= efi_systab.tables;
> >
> > early_memunmap(systab64, sizeof(*systab64));
> > + if (data)
> > + early_memunmap(data, sizeof(*data));
> > #ifdef CONFIG_X86_32
> > if (tmp >> 32) {
> > pr_err("EFI data located above 4GB, disabling EFI.\n");
> > @@ -631,6 +666,61 @@ static int __init efi_memmap_init(void)
> > return 0;
> > }
> >
> > +/*
> > + * For kexec kernel there's some special config table entries which could be
> > + * converted to virtual addresses after entering virtual mode. In kexec kernel
> > + * we need the physical addresses instead, thus passing them via setup_data
> > + * and update the entries to physical addresses in this function.
>
> Rewrite:
>
> "A number of config table entries get remapped to virtual addresses
> after entering EFI virtual mode. However, the kexec kernel requires
> their physical addresses therefore we pass them via setup_data and
> correct those entries to their respective physical addresses here."
Thanks for the rewriting. Will use.
>
> > + *
> > + * Currently only handles smbios which is necessary for HP z420.
>
> Didn't we say that this behavior is coming from a generic UEFI fw
> implementation and if so, no need to mention z420?
Yes, but till now I only reproduced this on z420 so how about below:
"Currently only handles smbios which is necessary for some firmware
implementation."
It might be general but also might only related to some version of
the general firmware implementation, it's hard to say...
>
> > + */
> > +static int __init efi_reuse_config(u64 tables, int nr_tables)
> > +{
> > + int i, sz, ret = 0;
> > + void *p, *tablep;
> > + struct efi_setup_data *data;
> > +
> > + if (!efi_setup)
> > + return 0;
> > +
> > + if (!efi_enabled(EFI_64BIT))
> > + return 0;
> > +
> > + data = early_memremap(efi_setup, sizeof(*data));
> > + if (!data) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > +
> > + if (!data->smbios)
> > + goto out_memremap;
> > +
> > + sz = sizeof(efi_config_table_64_t);
> > +
> > + p = tablep = early_memremap(tables, nr_tables * sz);
> > + if (!p) {
> > + pr_err("Could not map Configuration table!\n");
> > + ret = -ENOMEM;
> > + goto out_memremap;
> > + }
> > +
> > + for (i = 0; i < efi.systab->nr_tables; i++) {
> > + efi_guid_t guid;
> > +
> > + guid = ((efi_config_table_64_t *)p)->guid;
> > +
> > + if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
> > + ((efi_config_table_64_t *)p)->table = data->smbios;
> > + p += sz;
> > + }
> > + early_memunmap(tablep, nr_tables * sz);
> > +
> > +out_memremap:
> > + early_memunmap(data, sizeof(*data));
> > +out:
> > + return ret;
> > +}
> > +
> > void __init efi_init(void)
> > {
> > efi_char16_t *c16;
> > @@ -676,6 +766,8 @@ void __init efi_init(void)
> > efi.systab->hdr.revision >> 16,
> > efi.systab->hdr.revision & 0xffff, vendor);
> >
> > + efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
> > +
> > if (efi_config_init(arch_tables))
> > return;
> >
> > @@ -886,6 +978,50 @@ out_krealloc:
> > }
> >
> > /*
> > + * Map efi regions which was passed via setup_data. The virt_addr is a fixed
>
> were
Will update
>
> > + * addr which was used in first kernel in case kexec boot.
> ^
> of a
Will update
>
> > + */
> > +static int __init map_regions_fixed(void)
> > +{
> > + int i, s, ret = 0;
> > + u64 end, systab;
> > + unsigned long size;
> > + efi_memory_desc_t *md;
> > + struct efi_setup_data *data;
> > +
> > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > + data = early_memremap(efi_setup, s);
> > + if (!data) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
>
> newline.
Will remove
>
> > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > + efi_map_region_fixed(md); /* FIXME: add error handling */
> > + size = md->num_pages << PAGE_SHIFT;
> > + end = md->phys_addr + size;
> > +
> > + systab = (u64) (unsigned long) efi_phys.systab;
> > + if (md->phys_addr <= systab && systab < end) {
> > + systab += md->virt_addr - md->phys_addr;
> > + efi.systab = (efi_system_table_t *)(unsigned long)systab;
> > + }
> > + ret = save_runtime_map(md, i);
>
> Wait a minute, this is executed in the second, kexec-ed kernel, right?
> Why do we need to save the map there too?
Yes, nested kexec need this.
>
> > + if (ret)
> > + goto out_save_runtime;
> > + }
> > +
> > + early_memunmap(data, s);
> > + return 0;
> > +
> > +out_save_runtime:
> > + kfree(efi_runtime_map);
> > + nr_efi_runtime_map = 0;
> > + early_memunmap(data, s);
> > +out:
> > + return ret;
> > +}
> > +
> > +/*
> > * This function will switch the EFI runtime services to virtual mode.
> > * Essentially, we look through the EFI memmap and map every region that
> > * has the runtime attribute bit set in its memory descriptor into the
> > @@ -901,12 +1037,16 @@ out_krealloc:
> > * so that we're in a different address space when calling a runtime
> > * function. For function arguments passing we do copy the PGDs of the
> > * kernel page table into ->trampoline_pgd prior to each call.
> > + *
> > + * Specially for kexec boot, efi runtime maps in previous kernel should
> > + * be passed in via setup_data. In that case runtime ranges will be mapped
> > + * to the same virtual addresses exactly same as the ones in previous kernel.
>
> "... to the same ..exactly same as ... " sounds funny. What's wrong with
>
> "... to the same virtual addresses as the first kernel."
Will use above one.
--
Thanks for review
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 3:06 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 3:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
hpa-YMNOUZJC4hwAvxtiuMwx3w, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On 12/11/13 at 11:20pm, Borislav Petkov wrote:
> On Mon, Dec 09, 2013 at 05:42:22PM +0800, Dave Young wrote:
> > Add a new setup_data type SETUP_EFI for kexec use.
> > Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
> >
> > When entering virtual mode, directly mapping the efi runtime ragions which
> > we passed in previously. And skip the step to call SetVirtualAddressMap.
> >
> > Specially for HP z420 workstation we need save the smbios physical address.
> > The kernel boot sequence proceeds in the following order. Step 2
> > requires efi.smbios to be the physical address. However, I found that on
> > HP z420 EFI system table has a virtual address of SMBIOS in step 1. Hence,
> > we need set it back to the physical address with the smbios in
> > efi_setup_data. (When it is still the physical address, it simply sets
> > the same value.)
> >
> > 1. efi_init() - Set efi.smbios from EFI system table
> > 2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
> > 3. efi_enter_virtual_mode() - Map EFI ranges
> >
> > Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
> > HP z420 workstation.
> >
> > v2: refresh based on previous patch changes, code cleanup.
> > v3: use ioremap instead of phys_to_virt for efi_setup
> > v5: improve some code structure per comments from Matt
> > Boris: improve code structure, spell fix, etc.
> > Improve changelog from Toshi.
> > change the variable efi_setup to the physical address of efi setup_data
> > instead of the ioremapped virt address
> >
> > Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > ---
> > arch/x86/include/asm/efi.h | 11 ++
> > arch/x86/include/uapi/asm/bootparam.h | 1 +
> > arch/x86/kernel/setup.c | 3 +
> > arch/x86/platform/efi/efi.c | 195 ++++++++++++++++++++++++++++++----
> > 4 files changed, 187 insertions(+), 23 deletions(-)
>
> ...
>
> > @@ -115,6 +116,25 @@ static int __init setup_storage_paranoia(char *arg)
> > }
> > early_param("efi_no_storage_paranoia", setup_storage_paranoia);
> >
> > +void __init parse_efi_setup(u64 phys_addr)
> > +{
> > + struct setup_data *sd;
> > +
> > + if (!efi_enabled(EFI_64BIT)) {
> > + pr_warn("SETUP_EFI not supported on 32-bit\n");
> > + return;
> > + }
>
> Shouldn't this function be in two versions in efi_64.c and efi_32.c?
> This way you don't need this check with cryptic printk message.
Ok, will update.
>
> > +
> > + sd = early_memremap(phys_addr, sizeof(struct setup_data));
> > + if (!sd) {
> > + pr_warn("efi: early_memremap setup_data failed\n");
> > + return;
> > + }
> > + efi_setup = phys_addr + sizeof(struct setup_data);
> > + nr_efi_runtime_map = (sd->len - sizeof(struct efi_setup_data)) /
> > + sizeof(efi_memory_desc_t);
> > + early_memunmap(sd, sizeof(struct setup_data));
> > +}
> >
> > static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
> > {
> > @@ -494,18 +514,28 @@ static int __init efi_systab_init(void *phys)
> > {
> > if (efi_enabled(EFI_64BIT)) {
> > efi_system_table_64_t *systab64;
> > + struct efi_setup_data *data = NULL;
> > u64 tmp = 0;
> >
> > + if (efi_setup) {
> > + data = early_memremap(efi_setup, sizeof(*data));
> > + if (!data)
> > + return -ENOMEM;
> > + }
> > systab64 = early_memremap((unsigned long)phys,
> > sizeof(*systab64));
> > if (systab64 == NULL) {
> > pr_err("Couldn't map the system table!\n");
> > + if (data)
> > + early_memunmap(data, sizeof(*data));
> > return -ENOMEM;
> > }
> >
> > efi_systab.hdr = systab64->hdr;
> > - efi_systab.fw_vendor = systab64->fw_vendor;
> > - tmp |= systab64->fw_vendor;
> > +
> > + efi_systab.fw_vendor = data ? (unsigned long)data->fw_vendor :
> > + systab64->fw_vendor;
> > + tmp |= efi_systab.fw_vendor;
> > efi_systab.fw_revision = systab64->fw_revision;
> > efi_systab.con_in_handle = systab64->con_in_handle;
> > tmp |= systab64->con_in_handle;
> > @@ -519,15 +549,20 @@ static int __init efi_systab_init(void *phys)
> > tmp |= systab64->stderr_handle;
> > efi_systab.stderr = systab64->stderr;
> > tmp |= systab64->stderr;
> > - efi_systab.runtime = (void *)(unsigned long)systab64->runtime;
> > - tmp |= systab64->runtime;
> > + efi_systab.runtime = data ?
> > + (void *)(unsigned long)data->runtime :
> > + (void *)(unsigned long)systab64->runtime;
> > + tmp |= (unsigned long)efi_systab.runtime;
> > efi_systab.boottime = (void *)(unsigned long)systab64->boottime;
> > tmp |= systab64->boottime;
> > efi_systab.nr_tables = systab64->nr_tables;
> > - efi_systab.tables = systab64->tables;
> > - tmp |= systab64->tables;
> > + efi_systab.tables = data ? (unsigned long)data->tables :
> > + systab64->tables;
> > + tmp |= efi_systab.tables;
> >
> > early_memunmap(systab64, sizeof(*systab64));
> > + if (data)
> > + early_memunmap(data, sizeof(*data));
> > #ifdef CONFIG_X86_32
> > if (tmp >> 32) {
> > pr_err("EFI data located above 4GB, disabling EFI.\n");
> > @@ -631,6 +666,61 @@ static int __init efi_memmap_init(void)
> > return 0;
> > }
> >
> > +/*
> > + * For kexec kernel there's some special config table entries which could be
> > + * converted to virtual addresses after entering virtual mode. In kexec kernel
> > + * we need the physical addresses instead, thus passing them via setup_data
> > + * and update the entries to physical addresses in this function.
>
> Rewrite:
>
> "A number of config table entries get remapped to virtual addresses
> after entering EFI virtual mode. However, the kexec kernel requires
> their physical addresses therefore we pass them via setup_data and
> correct those entries to their respective physical addresses here."
Thanks for the rewriting. Will use.
>
> > + *
> > + * Currently only handles smbios which is necessary for HP z420.
>
> Didn't we say that this behavior is coming from a generic UEFI fw
> implementation and if so, no need to mention z420?
Yes, but till now I only reproduced this on z420 so how about below:
"Currently only handles smbios which is necessary for some firmware
implementation."
It might be general but also might only related to some version of
the general firmware implementation, it's hard to say...
>
> > + */
> > +static int __init efi_reuse_config(u64 tables, int nr_tables)
> > +{
> > + int i, sz, ret = 0;
> > + void *p, *tablep;
> > + struct efi_setup_data *data;
> > +
> > + if (!efi_setup)
> > + return 0;
> > +
> > + if (!efi_enabled(EFI_64BIT))
> > + return 0;
> > +
> > + data = early_memremap(efi_setup, sizeof(*data));
> > + if (!data) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > +
> > + if (!data->smbios)
> > + goto out_memremap;
> > +
> > + sz = sizeof(efi_config_table_64_t);
> > +
> > + p = tablep = early_memremap(tables, nr_tables * sz);
> > + if (!p) {
> > + pr_err("Could not map Configuration table!\n");
> > + ret = -ENOMEM;
> > + goto out_memremap;
> > + }
> > +
> > + for (i = 0; i < efi.systab->nr_tables; i++) {
> > + efi_guid_t guid;
> > +
> > + guid = ((efi_config_table_64_t *)p)->guid;
> > +
> > + if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
> > + ((efi_config_table_64_t *)p)->table = data->smbios;
> > + p += sz;
> > + }
> > + early_memunmap(tablep, nr_tables * sz);
> > +
> > +out_memremap:
> > + early_memunmap(data, sizeof(*data));
> > +out:
> > + return ret;
> > +}
> > +
> > void __init efi_init(void)
> > {
> > efi_char16_t *c16;
> > @@ -676,6 +766,8 @@ void __init efi_init(void)
> > efi.systab->hdr.revision >> 16,
> > efi.systab->hdr.revision & 0xffff, vendor);
> >
> > + efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
> > +
> > if (efi_config_init(arch_tables))
> > return;
> >
> > @@ -886,6 +978,50 @@ out_krealloc:
> > }
> >
> > /*
> > + * Map efi regions which was passed via setup_data. The virt_addr is a fixed
>
> were
Will update
>
> > + * addr which was used in first kernel in case kexec boot.
> ^
> of a
Will update
>
> > + */
> > +static int __init map_regions_fixed(void)
> > +{
> > + int i, s, ret = 0;
> > + u64 end, systab;
> > + unsigned long size;
> > + efi_memory_desc_t *md;
> > + struct efi_setup_data *data;
> > +
> > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > + data = early_memremap(efi_setup, s);
> > + if (!data) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
>
> newline.
Will remove
>
> > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > + efi_map_region_fixed(md); /* FIXME: add error handling */
> > + size = md->num_pages << PAGE_SHIFT;
> > + end = md->phys_addr + size;
> > +
> > + systab = (u64) (unsigned long) efi_phys.systab;
> > + if (md->phys_addr <= systab && systab < end) {
> > + systab += md->virt_addr - md->phys_addr;
> > + efi.systab = (efi_system_table_t *)(unsigned long)systab;
> > + }
> > + ret = save_runtime_map(md, i);
>
> Wait a minute, this is executed in the second, kexec-ed kernel, right?
> Why do we need to save the map there too?
Yes, nested kexec need this.
>
> > + if (ret)
> > + goto out_save_runtime;
> > + }
> > +
> > + early_memunmap(data, s);
> > + return 0;
> > +
> > +out_save_runtime:
> > + kfree(efi_runtime_map);
> > + nr_efi_runtime_map = 0;
> > + early_memunmap(data, s);
> > +out:
> > + return ret;
> > +}
> > +
> > +/*
> > * This function will switch the EFI runtime services to virtual mode.
> > * Essentially, we look through the EFI memmap and map every region that
> > * has the runtime attribute bit set in its memory descriptor into the
> > @@ -901,12 +1037,16 @@ out_krealloc:
> > * so that we're in a different address space when calling a runtime
> > * function. For function arguments passing we do copy the PGDs of the
> > * kernel page table into ->trampoline_pgd prior to each call.
> > + *
> > + * Specially for kexec boot, efi runtime maps in previous kernel should
> > + * be passed in via setup_data. In that case runtime ranges will be mapped
> > + * to the same virtual addresses exactly same as the ones in previous kernel.
>
> "... to the same ..exactly same as ... " sounds funny. What's wrong with
>
> "... to the same virtual addresses as the first kernel."
Will use above one.
--
Thanks for review
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 6:25 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 6:25 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
> > > + */
> > > +static int __init map_regions_fixed(void)
> > > +{
> > > + int i, s, ret = 0;
> > > + u64 end, systab;
> > > + unsigned long size;
> > > + efi_memory_desc_t *md;
> > > + struct efi_setup_data *data;
> > > +
> > > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > > + data = early_memremap(efi_setup, s);
> > > + if (!data) {
> > > + ret = -ENOMEM;
> > > + goto out;
> > > + }
> >
> > newline.
>
> Will remove
misread the comment, there's no new line here. Looks like you want a
new blank line here, ok..
>
> >
> > > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > > + efi_map_region_fixed(md); /* FIXME: add error handling */
> > > + size = md->num_pages << PAGE_SHIFT;
> > > + end = md->phys_addr + size;
> > > +
> > > + systab = (u64) (unsigned long) efi_phys.systab;
> > > + if (md->phys_addr <= systab && systab < end) {
> > > + systab += md->virt_addr - md->phys_addr;
> > > + efi.systab = (efi_system_table_t *)(unsigned long)systab;
> > > + }
> > > + ret = save_runtime_map(md, i);
> >
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 6:25 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 6:25 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
> > > + */
> > > +static int __init map_regions_fixed(void)
> > > +{
> > > + int i, s, ret = 0;
> > > + u64 end, systab;
> > > + unsigned long size;
> > > + efi_memory_desc_t *md;
> > > + struct efi_setup_data *data;
> > > +
> > > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > > + data = early_memremap(efi_setup, s);
> > > + if (!data) {
> > > + ret = -ENOMEM;
> > > + goto out;
> > > + }
> >
> > newline.
>
> Will remove
misread the comment, there's no new line here. Looks like you want a
new blank line here, ok..
>
> >
> > > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > > + efi_map_region_fixed(md); /* FIXME: add error handling */
> > > + size = md->num_pages << PAGE_SHIFT;
> > > + end = md->phys_addr + size;
> > > +
> > > + systab = (u64) (unsigned long) efi_phys.systab;
> > > + if (md->phys_addr <= systab && systab < end) {
> > > + systab += md->virt_addr - md->phys_addr;
> > > + efi.systab = (efi_system_table_t *)(unsigned long)systab;
> > > + }
> > > + ret = save_runtime_map(md, i);
> >
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 6:25 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 6:25 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
hpa-YMNOUZJC4hwAvxtiuMwx3w, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
> > > + */
> > > +static int __init map_regions_fixed(void)
> > > +{
> > > + int i, s, ret = 0;
> > > + u64 end, systab;
> > > + unsigned long size;
> > > + efi_memory_desc_t *md;
> > > + struct efi_setup_data *data;
> > > +
> > > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > > + data = early_memremap(efi_setup, s);
> > > + if (!data) {
> > > + ret = -ENOMEM;
> > > + goto out;
> > > + }
> >
> > newline.
>
> Will remove
misread the comment, there's no new line here. Looks like you want a
new blank line here, ok..
>
> >
> > > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > > + efi_map_region_fixed(md); /* FIXME: add error handling */
> > > + size = md->num_pages << PAGE_SHIFT;
> > > + end = md->phys_addr + size;
> > > +
> > > + systab = (u64) (unsigned long) efi_phys.systab;
> > > + if (md->phys_addr <= systab && systab < end) {
> > > + systab += md->virt_addr - md->phys_addr;
> > > + efi.systab = (efi_system_table_t *)(unsigned long)systab;
> > > + }
> > > + ret = save_runtime_map(md, i);
> >
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 7:17 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 7:17 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
> > >
> > > +void __init parse_efi_setup(u64 phys_addr)
> > > +{
> > > + struct setup_data *sd;
> > > +
> > > + if (!efi_enabled(EFI_64BIT)) {
> > > + pr_warn("SETUP_EFI not supported on 32-bit\n");
> > > + return;
> > > + }
> >
> > Shouldn't this function be in two versions in efi_64.c and efi_32.c?
> > This way you don't need this check with cryptic printk message.
>
> Ok, will update.
Rethink about this issue, moving them to efi_$(BITS).c I need move the
efi_setup from a static variable to an extern, It looks not worth.
Thanks
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 7:17 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 7:17 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
> > >
> > > +void __init parse_efi_setup(u64 phys_addr)
> > > +{
> > > + struct setup_data *sd;
> > > +
> > > + if (!efi_enabled(EFI_64BIT)) {
> > > + pr_warn("SETUP_EFI not supported on 32-bit\n");
> > > + return;
> > > + }
> >
> > Shouldn't this function be in two versions in efi_64.c and efi_32.c?
> > This way you don't need this check with cryptic printk message.
>
> Ok, will update.
Rethink about this issue, moving them to efi_$(BITS).c I need move the
efi_setup from a static variable to an extern, It looks not worth.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 7:17 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-12 7:17 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
hpa-YMNOUZJC4hwAvxtiuMwx3w, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
> > >
> > > +void __init parse_efi_setup(u64 phys_addr)
> > > +{
> > > + struct setup_data *sd;
> > > +
> > > + if (!efi_enabled(EFI_64BIT)) {
> > > + pr_warn("SETUP_EFI not supported on 32-bit\n");
> > > + return;
> > > + }
> >
> > Shouldn't this function be in two versions in efi_64.c and efi_32.c?
> > This way you don't need this check with cryptic printk message.
>
> Ok, will update.
Rethink about this issue, moving them to efi_$(BITS).c I need move the
efi_setup from a static variable to an extern, It looks not worth.
Thanks
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 21:04 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-12 21:04 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On Thu, Dec 12, 2013 at 03:17:43PM +0800, Dave Young wrote:
> Rethink about this issue, moving them to efi_$(BITS).c I need move the
> efi_setup from a static variable to an extern, It looks not worth.
Dave, would you please do what is suggested to you? A big part of
the efi code is split into 32-bit and 64-bit functionality. If you
have a serious argument why it shouldn't be done so then sure, by all
means, but stop coming up with silly arguments like having an extern
declaration is a bad thing. Please.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 21:04 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-12 21:04 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On Thu, Dec 12, 2013 at 03:17:43PM +0800, Dave Young wrote:
> Rethink about this issue, moving them to efi_$(BITS).c I need move the
> efi_setup from a static variable to an extern, It looks not worth.
Dave, would you please do what is suggested to you? A big part of
the efi code is split into 32-bit and 64-bit functionality. If you
have a serious argument why it shouldn't be done so then sure, by all
means, but stop coming up with silly arguments like having an extern
declaration is a bad thing. Please.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-12 21:04 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-12 21:04 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On Thu, Dec 12, 2013 at 03:17:43PM +0800, Dave Young wrote:
> Rethink about this issue, moving them to efi_$(BITS).c I need move the
> efi_setup from a static variable to an extern, It looks not worth.
Dave, would you please do what is suggested to you? A big part of
the efi code is split into 32-bit and 64-bit functionality. If you
have a serious argument why it shouldn't be done so then sure, by all
means, but stop coming up with silly arguments like having an extern
declaration is a bad thing. Please.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-13 7:27 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-13 7:27 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On 12/12/13 at 10:04pm, Borislav Petkov wrote:
> On Thu, Dec 12, 2013 at 03:17:43PM +0800, Dave Young wrote:
> > Rethink about this issue, moving them to efi_$(BITS).c I need move the
> > efi_setup from a static variable to an extern, It looks not worth.
>
> Dave, would you please do what is suggested to you? A big part of
> the efi code is split into 32-bit and 64-bit functionality. If you
> have a serious argument why it shouldn't be done so then sure, by all
> means, but stop coming up with silly arguments like having an extern
> declaration is a bad thing. Please.
Ok, will do.
--
Thanks
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-13 7:27 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-13 7:27 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On 12/12/13 at 10:04pm, Borislav Petkov wrote:
> On Thu, Dec 12, 2013 at 03:17:43PM +0800, Dave Young wrote:
> > Rethink about this issue, moving them to efi_$(BITS).c I need move the
> > efi_setup from a static variable to an extern, It looks not worth.
>
> Dave, would you please do what is suggested to you? A big part of
> the efi code is split into 32-bit and 64-bit functionality. If you
> have a serious argument why it shouldn't be done so then sure, by all
> means, but stop coming up with silly arguments like having an extern
> declaration is a bad thing. Please.
Ok, will do.
--
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 09/14] efi: passing kexec necessary efi data via setup_data
@ 2013-12-13 7:27 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-13 7:27 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On 12/12/13 at 10:04pm, Borislav Petkov wrote:
> On Thu, Dec 12, 2013 at 03:17:43PM +0800, Dave Young wrote:
> > Rethink about this issue, moving them to efi_$(BITS).c I need move the
> > efi_setup from a static variable to an extern, It looks not worth.
>
> Dave, would you please do what is suggested to you? A big part of
> the efi code is split into 32-bit and 64-bit functionality. If you
> have a serious argument why it shouldn't be done so then sure, by all
> means, but stop coming up with silly arguments like having an extern
> declaration is a bad thing. Please.
Ok, will do.
--
Thanks
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
For kexec/kdump kernel efi runtime mappings are saved, printing original whole
memmap ranges does not make sense anymore. So introduce a new function to only
print runtime maps in case kexec/kdump kernel is used.
changelog:
Matt: use efi_setup instead of esdata
share function print_efi_memmap for both normal and kexec boot.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/platform/efi/efi.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 69a6ec2..94a1cbc 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -423,19 +423,16 @@ int __init efi_memblock_x86_reserve_range(void)
return 0;
}
-static void __init print_efi_memmap(void)
+static void __init print_efi_memmap(void *map, int nr_map, int md_size)
{
#ifdef EFI_DEBUG
efi_memory_desc_t *md;
void *p;
int i;
- for (p = memmap.map, i = 0;
- p < memmap.map_end;
- p += memmap.desc_size, i++) {
+ for (p = map, i = 0; i < nr_map; p += md_size, i++) {
md = p;
- pr_info("mem%02u: type=%u, attr=0x%llx, "
- "range=[0x%016llx-0x%016llx) (%lluMB)\n",
+ pr_info("mem%02u: type=%u, attr=0x%llx, range=[0x%016llx-0x%016llx) (%lluMB)\n",
i, md->type, md->attribute, md->phys_addr,
md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT),
(md->num_pages >> (20 - EFI_PAGE_SHIFT)));
@@ -797,7 +794,20 @@ void __init efi_init(void)
x86_platform.set_wallclock = efi_set_rtc_mmss;
}
#endif
- print_efi_memmap();
+ if (efi_setup) {
+ int s;
+ struct efi_setup_data *data;
+
+ s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
+ data = early_memremap(efi_setup, s);
+ if (!data)
+ return;
+ print_efi_memmap(data->map, nr_efi_runtime_map,
+ sizeof(data->map[0]));
+ early_memunmap(data, s);
+ } else {
+ print_efi_memmap(memmap.map, memmap.nr_map, memmap.desc_size);
+ }
}
void __init efi_late_init(void)
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
For kexec/kdump kernel efi runtime mappings are saved, printing original whole
memmap ranges does not make sense anymore. So introduce a new function to only
print runtime maps in case kexec/kdump kernel is used.
changelog:
Matt: use efi_setup instead of esdata
share function print_efi_memmap for both normal and kexec boot.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/platform/efi/efi.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 69a6ec2..94a1cbc 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -423,19 +423,16 @@ int __init efi_memblock_x86_reserve_range(void)
return 0;
}
-static void __init print_efi_memmap(void)
+static void __init print_efi_memmap(void *map, int nr_map, int md_size)
{
#ifdef EFI_DEBUG
efi_memory_desc_t *md;
void *p;
int i;
- for (p = memmap.map, i = 0;
- p < memmap.map_end;
- p += memmap.desc_size, i++) {
+ for (p = map, i = 0; i < nr_map; p += md_size, i++) {
md = p;
- pr_info("mem%02u: type=%u, attr=0x%llx, "
- "range=[0x%016llx-0x%016llx) (%lluMB)\n",
+ pr_info("mem%02u: type=%u, attr=0x%llx, range=[0x%016llx-0x%016llx) (%lluMB)\n",
i, md->type, md->attribute, md->phys_addr,
md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT),
(md->num_pages >> (20 - EFI_PAGE_SHIFT)));
@@ -797,7 +794,20 @@ void __init efi_init(void)
x86_platform.set_wallclock = efi_set_rtc_mmss;
}
#endif
- print_efi_memmap();
+ if (efi_setup) {
+ int s;
+ struct efi_setup_data *data;
+
+ s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
+ data = early_memremap(efi_setup, s);
+ if (!data)
+ return;
+ print_efi_memmap(data->map, nr_efi_runtime_map,
+ sizeof(data->map[0]));
+ early_memunmap(data, s);
+ } else {
+ print_efi_memmap(memmap.map, memmap.nr_map, memmap.desc_size);
+ }
}
void __init efi_late_init(void)
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
For kexec/kdump kernel efi runtime mappings are saved, printing original whole
memmap ranges does not make sense anymore. So introduce a new function to only
print runtime maps in case kexec/kdump kernel is used.
changelog:
Matt: use efi_setup instead of esdata
share function print_efi_memmap for both normal and kexec boot.
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
arch/x86/platform/efi/efi.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 69a6ec2..94a1cbc 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -423,19 +423,16 @@ int __init efi_memblock_x86_reserve_range(void)
return 0;
}
-static void __init print_efi_memmap(void)
+static void __init print_efi_memmap(void *map, int nr_map, int md_size)
{
#ifdef EFI_DEBUG
efi_memory_desc_t *md;
void *p;
int i;
- for (p = memmap.map, i = 0;
- p < memmap.map_end;
- p += memmap.desc_size, i++) {
+ for (p = map, i = 0; i < nr_map; p += md_size, i++) {
md = p;
- pr_info("mem%02u: type=%u, attr=0x%llx, "
- "range=[0x%016llx-0x%016llx) (%lluMB)\n",
+ pr_info("mem%02u: type=%u, attr=0x%llx, range=[0x%016llx-0x%016llx) (%lluMB)\n",
i, md->type, md->attribute, md->phys_addr,
md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT),
(md->num_pages >> (20 - EFI_PAGE_SHIFT)));
@@ -797,7 +794,20 @@ void __init efi_init(void)
x86_platform.set_wallclock = efi_set_rtc_mmss;
}
#endif
- print_efi_memmap();
+ if (efi_setup) {
+ int s;
+ struct efi_setup_data *data;
+
+ s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
+ data = early_memremap(efi_setup, s);
+ if (!data)
+ return;
+ print_efi_memmap(data->map, nr_efi_runtime_map,
+ sizeof(data->map[0]));
+ early_memunmap(data, s);
+ } else {
+ print_efi_memmap(memmap.map, memmap.nr_map, memmap.desc_size);
+ }
}
void __init efi_late_init(void)
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
2013-12-09 9:42 ` Dave Young
@ 2013-12-13 16:01 ` Borislav Petkov
-1 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-13 16:01 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On Mon, Dec 09, 2013 at 05:42:23PM +0800, Dave Young wrote:
> For kexec/kdump kernel efi runtime mappings are saved, printing original whole
> memmap ranges does not make sense anymore. So introduce a new function to only
> print runtime maps in case kexec/kdump kernel is used.
>
> changelog:
> Matt: use efi_setup instead of esdata
> share function print_efi_memmap for both normal and kexec boot.
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/platform/efi/efi.c | 24 +++++++++++++++++-------
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 69a6ec2..94a1cbc 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -423,19 +423,16 @@ int __init efi_memblock_x86_reserve_range(void)
> return 0;
> }
>
> -static void __init print_efi_memmap(void)
> +static void __init print_efi_memmap(void *map, int nr_map, int md_size)
> {
> #ifdef EFI_DEBUG
> efi_memory_desc_t *md;
> void *p;
> int i;
>
> - for (p = memmap.map, i = 0;
> - p < memmap.map_end;
> - p += memmap.desc_size, i++) {
> + for (p = map, i = 0; i < nr_map; p += md_size, i++) {
> md = p;
> - pr_info("mem%02u: type=%u, attr=0x%llx, "
> - "range=[0x%016llx-0x%016llx) (%lluMB)\n",
> + pr_info("mem%02u: type=%u, attr=0x%llx, range=[0x%016llx-0x%016llx) (%lluMB)\n",
> i, md->type, md->attribute, md->phys_addr,
> md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT),
> (md->num_pages >> (20 - EFI_PAGE_SHIFT)));
> @@ -797,7 +794,20 @@ void __init efi_init(void)
> x86_platform.set_wallclock = efi_set_rtc_mmss;
> }
> #endif
> - print_efi_memmap();
> + if (efi_setup) {
> + int s;
> + struct efi_setup_data *data;
> +
> + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> + data = early_memremap(efi_setup, s);
> + if (!data)
> + return;
> + print_efi_memmap(data->map, nr_efi_runtime_map,
> + sizeof(data->map[0]));
> + early_memunmap(data, s);
Well, if you call print_efi_memmap() in parse_efi_setup() you can save
yourself that map/unmaping no?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-13 16:01 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-13 16:01 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On Mon, Dec 09, 2013 at 05:42:23PM +0800, Dave Young wrote:
> For kexec/kdump kernel efi runtime mappings are saved, printing original whole
> memmap ranges does not make sense anymore. So introduce a new function to only
> print runtime maps in case kexec/kdump kernel is used.
>
> changelog:
> Matt: use efi_setup instead of esdata
> share function print_efi_memmap for both normal and kexec boot.
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/platform/efi/efi.c | 24 +++++++++++++++++-------
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 69a6ec2..94a1cbc 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -423,19 +423,16 @@ int __init efi_memblock_x86_reserve_range(void)
> return 0;
> }
>
> -static void __init print_efi_memmap(void)
> +static void __init print_efi_memmap(void *map, int nr_map, int md_size)
> {
> #ifdef EFI_DEBUG
> efi_memory_desc_t *md;
> void *p;
> int i;
>
> - for (p = memmap.map, i = 0;
> - p < memmap.map_end;
> - p += memmap.desc_size, i++) {
> + for (p = map, i = 0; i < nr_map; p += md_size, i++) {
> md = p;
> - pr_info("mem%02u: type=%u, attr=0x%llx, "
> - "range=[0x%016llx-0x%016llx) (%lluMB)\n",
> + pr_info("mem%02u: type=%u, attr=0x%llx, range=[0x%016llx-0x%016llx) (%lluMB)\n",
> i, md->type, md->attribute, md->phys_addr,
> md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT),
> (md->num_pages >> (20 - EFI_PAGE_SHIFT)));
> @@ -797,7 +794,20 @@ void __init efi_init(void)
> x86_platform.set_wallclock = efi_set_rtc_mmss;
> }
> #endif
> - print_efi_memmap();
> + if (efi_setup) {
> + int s;
> + struct efi_setup_data *data;
> +
> + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> + data = early_memremap(efi_setup, s);
> + if (!data)
> + return;
> + print_efi_memmap(data->map, nr_efi_runtime_map,
> + sizeof(data->map[0]));
> + early_memunmap(data, s);
Well, if you call print_efi_memmap() in parse_efi_setup() you can save
yourself that map/unmaping no?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-16 2:00 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 2:00 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
> > - print_efi_memmap();
> > + if (efi_setup) {
> > + int s;
> > + struct efi_setup_data *data;
> > +
> > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > + data = early_memremap(efi_setup, s);
> > + if (!data)
> > + return;
> > + print_efi_memmap(data->map, nr_efi_runtime_map,
> > + sizeof(data->map[0]));
> > + early_memunmap(data, s);
>
> Well, if you call print_efi_memmap() in parse_efi_setup() you can save
> yourself that map/unmaping no?
In parse_efi_setup, I need map twice as well:
mapping sizeof(struct setup_data) to get the payload len, then mapping
the data->map again and call print_efi_memmap..
Another where what I print in this patch is same position what non-kexec kernel
does, it looks better that print them only if earlier init is ok.
--
Thanks for review
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-16 2:00 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 2:00 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
> > - print_efi_memmap();
> > + if (efi_setup) {
> > + int s;
> > + struct efi_setup_data *data;
> > +
> > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > + data = early_memremap(efi_setup, s);
> > + if (!data)
> > + return;
> > + print_efi_memmap(data->map, nr_efi_runtime_map,
> > + sizeof(data->map[0]));
> > + early_memunmap(data, s);
>
> Well, if you call print_efi_memmap() in parse_efi_setup() you can save
> yourself that map/unmaping no?
In parse_efi_setup, I need map twice as well:
mapping sizeof(struct setup_data) to get the payload len, then mapping
the data->map again and call print_efi_memmap..
Another where what I print in this patch is same position what non-kexec kernel
does, it looks better that print them only if earlier init is ok.
--
Thanks for review
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-16 2:00 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-16 2:00 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
hpa-YMNOUZJC4hwAvxtiuMwx3w, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
> > - print_efi_memmap();
> > + if (efi_setup) {
> > + int s;
> > + struct efi_setup_data *data;
> > +
> > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > + data = early_memremap(efi_setup, s);
> > + if (!data)
> > + return;
> > + print_efi_memmap(data->map, nr_efi_runtime_map,
> > + sizeof(data->map[0]));
> > + early_memunmap(data, s);
>
> Well, if you call print_efi_memmap() in parse_efi_setup() you can save
> yourself that map/unmaping no?
In parse_efi_setup, I need map twice as well:
mapping sizeof(struct setup_data) to get the payload len, then mapping
the data->map again and call print_efi_memmap..
Another where what I print in this patch is same position what non-kexec kernel
does, it looks better that print them only if earlier init is ok.
--
Thanks for review
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-16 11:33 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-16 11:33 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On Mon, Dec 16, 2013 at 10:00:10AM +0800, Dave Young wrote:
> > > - print_efi_memmap();
> > > + if (efi_setup) {
> > > + int s;
> > > + struct efi_setup_data *data;
> > > +
> > > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > > + data = early_memremap(efi_setup, s);
> > > + if (!data)
> > > + return;
> > > + print_efi_memmap(data->map, nr_efi_runtime_map,
> > > + sizeof(data->map[0]));
> > > + early_memunmap(data, s);
> >
> > Well, if you call print_efi_memmap() in parse_efi_setup() you can save
> > yourself that map/unmaping no?
>
> In parse_efi_setup, I need map twice as well:
Well, your v6 has a something completely different:
void __init parse_efi_setup(u64 phys_addr)
{
efi_setup = phys_addr;
}
There's no mapping at all anymore. So please redo your reply against v6.
> Another where what I print in this patch is same position what
> non-kexec kernel does, it looks better that print them only if earlier
> init is ok.
-ENOPARSE.
All I'm saying is, if you're going to memremap/memunmap efi_setup,
then do it once in efi_setup_init() as you do already and call
print_efi_memmap from there - no need to do work twice for no reason.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-16 11:33 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-16 11:33 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On Mon, Dec 16, 2013 at 10:00:10AM +0800, Dave Young wrote:
> > > - print_efi_memmap();
> > > + if (efi_setup) {
> > > + int s;
> > > + struct efi_setup_data *data;
> > > +
> > > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > > + data = early_memremap(efi_setup, s);
> > > + if (!data)
> > > + return;
> > > + print_efi_memmap(data->map, nr_efi_runtime_map,
> > > + sizeof(data->map[0]));
> > > + early_memunmap(data, s);
> >
> > Well, if you call print_efi_memmap() in parse_efi_setup() you can save
> > yourself that map/unmaping no?
>
> In parse_efi_setup, I need map twice as well:
Well, your v6 has a something completely different:
void __init parse_efi_setup(u64 phys_addr)
{
efi_setup = phys_addr;
}
There's no mapping at all anymore. So please redo your reply against v6.
> Another where what I print in this patch is same position what
> non-kexec kernel does, it looks better that print them only if earlier
> init is ok.
-ENOPARSE.
All I'm saying is, if you're going to memremap/memunmap efi_setup,
then do it once in efi_setup_init() as you do already and call
print_efi_memmap from there - no need to do work twice for no reason.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-16 11:33 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-16 11:33 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On Mon, Dec 16, 2013 at 10:00:10AM +0800, Dave Young wrote:
> > > - print_efi_memmap();
> > > + if (efi_setup) {
> > > + int s;
> > > + struct efi_setup_data *data;
> > > +
> > > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > > + data = early_memremap(efi_setup, s);
> > > + if (!data)
> > > + return;
> > > + print_efi_memmap(data->map, nr_efi_runtime_map,
> > > + sizeof(data->map[0]));
> > > + early_memunmap(data, s);
> >
> > Well, if you call print_efi_memmap() in parse_efi_setup() you can save
> > yourself that map/unmaping no?
>
> In parse_efi_setup, I need map twice as well:
Well, your v6 has a something completely different:
void __init parse_efi_setup(u64 phys_addr)
{
efi_setup = phys_addr;
}
There's no mapping at all anymore. So please redo your reply against v6.
> Another where what I print in this patch is same position what
> non-kexec kernel does, it looks better that print them only if earlier
> init is ok.
-ENOPARSE.
All I'm saying is, if you're going to memremap/memunmap efi_setup,
then do it once in efi_setup_init() as you do already and call
print_efi_memmap from there - no need to do work twice for no reason.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-17 6:34 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-17 6:34 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On 12/16/13 at 12:33pm, Borislav Petkov wrote:
> On Mon, Dec 16, 2013 at 10:00:10AM +0800, Dave Young wrote:
> > > > - print_efi_memmap();
> > > > + if (efi_setup) {
> > > > + int s;
> > > > + struct efi_setup_data *data;
> > > > +
> > > > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > > > + data = early_memremap(efi_setup, s);
> > > > + if (!data)
> > > > + return;
> > > > + print_efi_memmap(data->map, nr_efi_runtime_map,
> > > > + sizeof(data->map[0]));
> > > > + early_memunmap(data, s);
> > >
> > > Well, if you call print_efi_memmap() in parse_efi_setup() you can save
> > > yourself that map/unmaping no?
> >
> > In parse_efi_setup, I need map twice as well:
>
> Well, your v6 has a something completely different:
>
> void __init parse_efi_setup(u64 phys_addr)
> {
> efi_setup = phys_addr;
> }
>
> There's no mapping at all anymore. So please redo your reply against v6.
They are moved to efi.c efi_setup_init(), I'm not sure if I expained clear
enough, in current code parse_efi_setup only accept one argument phys_addr
so I will mapping it with sizeof(struct setup_data) to get the payload size
then get the nr_efi_runtime_map. This is a simplification from the old
implementation.
Based on current implementation, yes, I can add back another argument data_len
to avoid the 1st mapping thus I can print efi memmap as you said.
In this way I need export another extern for the data_len though.
>
> > Another where what I print in this patch is same position what
> > non-kexec kernel does, it looks better that print them only if earlier
> > init is ok.
>
> -ENOPARSE.
What do you mean about NOPARSE, do you want another function name like
save_efi_setup()?
>
> All I'm saying is, if you're going to memremap/memunmap efi_setup,
> then do it once in efi_setup_init() as you do already and call
> print_efi_memmap from there - no need to do work twice for no reason.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-17 6:34 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-17 6:34 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On 12/16/13 at 12:33pm, Borislav Petkov wrote:
> On Mon, Dec 16, 2013 at 10:00:10AM +0800, Dave Young wrote:
> > > > - print_efi_memmap();
> > > > + if (efi_setup) {
> > > > + int s;
> > > > + struct efi_setup_data *data;
> > > > +
> > > > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > > > + data = early_memremap(efi_setup, s);
> > > > + if (!data)
> > > > + return;
> > > > + print_efi_memmap(data->map, nr_efi_runtime_map,
> > > > + sizeof(data->map[0]));
> > > > + early_memunmap(data, s);
> > >
> > > Well, if you call print_efi_memmap() in parse_efi_setup() you can save
> > > yourself that map/unmaping no?
> >
> > In parse_efi_setup, I need map twice as well:
>
> Well, your v6 has a something completely different:
>
> void __init parse_efi_setup(u64 phys_addr)
> {
> efi_setup = phys_addr;
> }
>
> There's no mapping at all anymore. So please redo your reply against v6.
They are moved to efi.c efi_setup_init(), I'm not sure if I expained clear
enough, in current code parse_efi_setup only accept one argument phys_addr
so I will mapping it with sizeof(struct setup_data) to get the payload size
then get the nr_efi_runtime_map. This is a simplification from the old
implementation.
Based on current implementation, yes, I can add back another argument data_len
to avoid the 1st mapping thus I can print efi memmap as you said.
In this way I need export another extern for the data_len though.
>
> > Another where what I print in this patch is same position what
> > non-kexec kernel does, it looks better that print them only if earlier
> > init is ok.
>
> -ENOPARSE.
What do you mean about NOPARSE, do you want another function name like
save_efi_setup()?
>
> All I'm saying is, if you're going to memremap/memunmap efi_setup,
> then do it once in efi_setup_init() as you do already and call
> print_efi_memmap from there - no need to do work twice for no reason.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-17 6:34 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-17 6:34 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
hpa-YMNOUZJC4hwAvxtiuMwx3w, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On 12/16/13 at 12:33pm, Borislav Petkov wrote:
> On Mon, Dec 16, 2013 at 10:00:10AM +0800, Dave Young wrote:
> > > > - print_efi_memmap();
> > > > + if (efi_setup) {
> > > > + int s;
> > > > + struct efi_setup_data *data;
> > > > +
> > > > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > > > + data = early_memremap(efi_setup, s);
> > > > + if (!data)
> > > > + return;
> > > > + print_efi_memmap(data->map, nr_efi_runtime_map,
> > > > + sizeof(data->map[0]));
> > > > + early_memunmap(data, s);
> > >
> > > Well, if you call print_efi_memmap() in parse_efi_setup() you can save
> > > yourself that map/unmaping no?
> >
> > In parse_efi_setup, I need map twice as well:
>
> Well, your v6 has a something completely different:
>
> void __init parse_efi_setup(u64 phys_addr)
> {
> efi_setup = phys_addr;
> }
>
> There's no mapping at all anymore. So please redo your reply against v6.
They are moved to efi.c efi_setup_init(), I'm not sure if I expained clear
enough, in current code parse_efi_setup only accept one argument phys_addr
so I will mapping it with sizeof(struct setup_data) to get the payload size
then get the nr_efi_runtime_map. This is a simplification from the old
implementation.
Based on current implementation, yes, I can add back another argument data_len
to avoid the 1st mapping thus I can print efi memmap as you said.
In this way I need export another extern for the data_len though.
>
> > Another where what I print in this patch is same position what
> > non-kexec kernel does, it looks better that print them only if earlier
> > init is ok.
>
> -ENOPARSE.
What do you mean about NOPARSE, do you want another function name like
save_efi_setup()?
>
> All I'm saying is, if you're going to memremap/memunmap efi_setup,
> then do it once in efi_setup_init() as you do already and call
> print_efi_memmap from there - no need to do work twice for no reason.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-17 15:58 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-17 15:58 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On Tue, Dec 17, 2013 at 02:34:36PM +0800, Dave Young wrote:
> They are moved to efi.c efi_setup_init(), I'm not sure if I expained
> clear enough, in current code parse_efi_setup only accept one argument
> phys_addr so I will mapping it with sizeof(struct setup_data) to
> get the payload size then get the nr_efi_runtime_map. This is a
> simplification from the old implementation.
>
> Based on current implementation, yes, I can add back another argument
> data_len to avoid the 1st mapping thus I can print efi memmap as you
> said.
>
> In this way I need export another extern for the data_len though.
Well, think about it: do you want to do the memremap/unmap a second time
*just* to print the memmap in the efi kernel or do you want to do the
memremap/unmap only once and do the work once?
If you say you don't care about speed and wasting cycles then I'm
certainly fine with that as I've spent more time hinting at the
performance aspect than I'd like to.
> What do you mean about NOPARSE, do you want another function name like
> save_efi_setup()?
-ENOPARSE means I cannot parse what you said above.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-17 15:58 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-17 15:58 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On Tue, Dec 17, 2013 at 02:34:36PM +0800, Dave Young wrote:
> They are moved to efi.c efi_setup_init(), I'm not sure if I expained
> clear enough, in current code parse_efi_setup only accept one argument
> phys_addr so I will mapping it with sizeof(struct setup_data) to
> get the payload size then get the nr_efi_runtime_map. This is a
> simplification from the old implementation.
>
> Based on current implementation, yes, I can add back another argument
> data_len to avoid the 1st mapping thus I can print efi memmap as you
> said.
>
> In this way I need export another extern for the data_len though.
Well, think about it: do you want to do the memremap/unmap a second time
*just* to print the memmap in the efi kernel or do you want to do the
memremap/unmap only once and do the work once?
If you say you don't care about speed and wasting cycles then I'm
certainly fine with that as I've spent more time hinting at the
performance aspect than I'd like to.
> What do you mean about NOPARSE, do you want another function name like
> save_efi_setup()?
-ENOPARSE means I cannot parse what you said above.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-17 15:58 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-17 15:58 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On Tue, Dec 17, 2013 at 02:34:36PM +0800, Dave Young wrote:
> They are moved to efi.c efi_setup_init(), I'm not sure if I expained
> clear enough, in current code parse_efi_setup only accept one argument
> phys_addr so I will mapping it with sizeof(struct setup_data) to
> get the payload size then get the nr_efi_runtime_map. This is a
> simplification from the old implementation.
>
> Based on current implementation, yes, I can add back another argument
> data_len to avoid the 1st mapping thus I can print efi memmap as you
> said.
>
> In this way I need export another extern for the data_len though.
Well, think about it: do you want to do the memremap/unmap a second time
*just* to print the memmap in the efi kernel or do you want to do the
memremap/unmap only once and do the work once?
If you say you don't care about speed and wasting cycles then I'm
certainly fine with that as I've spent more time hinting at the
performance aspect than I'd like to.
> What do you mean about NOPARSE, do you want another function name like
> save_efi_setup()?
-ENOPARSE means I cannot parse what you said above.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-18 2:06 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-18 2:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On 12/17/13 at 04:58pm, Borislav Petkov wrote:
> On Tue, Dec 17, 2013 at 02:34:36PM +0800, Dave Young wrote:
> > They are moved to efi.c efi_setup_init(), I'm not sure if I expained
> > clear enough, in current code parse_efi_setup only accept one argument
> > phys_addr so I will mapping it with sizeof(struct setup_data) to
> > get the payload size then get the nr_efi_runtime_map. This is a
> > simplification from the old implementation.
> >
> > Based on current implementation, yes, I can add back another argument
> > data_len to avoid the 1st mapping thus I can print efi memmap as you
> > said.
> >
> > In this way I need export another extern for the data_len though.
>
> Well, think about it: do you want to do the memremap/unmap a second time
> *just* to print the memmap in the efi kernel or do you want to do the
> memremap/unmap only once and do the work once?
>
> If you say you don't care about speed and wasting cycles then I'm
> certainly fine with that as I've spent more time hinting at the
> performance aspect than I'd like to.
For these non critical path I would prefer the code which should be easier to
be understood. But yes I have managed to work out what you want in latest
version. Of course I appreciate your time for reviewing those patches.
Thanks.
>
> > What do you mean about NOPARSE, do you want another function name like
> > save_efi_setup()?
>
> -ENOPARSE means I cannot parse what you said above.
Ok.
Thanks
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-18 2:06 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-18 2:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On 12/17/13 at 04:58pm, Borislav Petkov wrote:
> On Tue, Dec 17, 2013 at 02:34:36PM +0800, Dave Young wrote:
> > They are moved to efi.c efi_setup_init(), I'm not sure if I expained
> > clear enough, in current code parse_efi_setup only accept one argument
> > phys_addr so I will mapping it with sizeof(struct setup_data) to
> > get the payload size then get the nr_efi_runtime_map. This is a
> > simplification from the old implementation.
> >
> > Based on current implementation, yes, I can add back another argument
> > data_len to avoid the 1st mapping thus I can print efi memmap as you
> > said.
> >
> > In this way I need export another extern for the data_len though.
>
> Well, think about it: do you want to do the memremap/unmap a second time
> *just* to print the memmap in the efi kernel or do you want to do the
> memremap/unmap only once and do the work once?
>
> If you say you don't care about speed and wasting cycles then I'm
> certainly fine with that as I've spent more time hinting at the
> performance aspect than I'd like to.
For these non critical path I would prefer the code which should be easier to
be understood. But yes I have managed to work out what you want in latest
version. Of course I appreciate your time for reviewing those patches.
Thanks.
>
> > What do you mean about NOPARSE, do you want another function name like
> > save_efi_setup()?
>
> -ENOPARSE means I cannot parse what you said above.
Ok.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec
@ 2013-12-18 2:06 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-18 2:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
hpa-YMNOUZJC4hwAvxtiuMwx3w, vgoyal-H+wXaHxf7aLQT0dZR+AlfA
On 12/17/13 at 04:58pm, Borislav Petkov wrote:
> On Tue, Dec 17, 2013 at 02:34:36PM +0800, Dave Young wrote:
> > They are moved to efi.c efi_setup_init(), I'm not sure if I expained
> > clear enough, in current code parse_efi_setup only accept one argument
> > phys_addr so I will mapping it with sizeof(struct setup_data) to
> > get the payload size then get the nr_efi_runtime_map. This is a
> > simplification from the old implementation.
> >
> > Based on current implementation, yes, I can add back another argument
> > data_len to avoid the 1st mapping thus I can print efi memmap as you
> > said.
> >
> > In this way I need export another extern for the data_len though.
>
> Well, think about it: do you want to do the memremap/unmap a second time
> *just* to print the memmap in the efi kernel or do you want to do the
> memremap/unmap only once and do the work once?
>
> If you say you don't care about speed and wasting cycles then I'm
> certainly fine with that as I've spent more time hinting at the
> performance aspect than I'd like to.
For these non critical path I would prefer the code which should be easier to
be understood. But yes I have managed to work out what you want in latest
version. Of course I appreciate your time for reviewing those patches.
Thanks.
>
> > What do you mean about NOPARSE, do you want another function name like
> > save_efi_setup()?
>
> -ENOPARSE means I cannot parse what you said above.
Ok.
Thanks
Dave
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH v5 11/14] x86: add xloadflags bit for efi runtime support on kexec
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
Old kexec-tools can not load new kernel. The reason is kexec-tools do not fill
efi_info in x86 setup header previously, thus efi failed to initialize.
In new kexec-tools it will by default fill efi_info and pass other efi required
infomation to 2nd kernel so kexec kernel efi initialization can succeed finally.
To prevent from breaking userspace, add a new xloadflags bit so kexec-tools
can check the flag and switch to old logic.
changelog:
Matt: +&& defined(CONFIG_KEXEC)
improve patch description.
HPA: document the flag.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
---
Documentation/x86/boot.txt | 3 +++
| 9 ++++++++-
arch/x86/include/uapi/asm/bootparam.h | 1 +
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index f4f268c..cb81741d 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -608,6 +608,9 @@ Protocol: 2.12+
- If 1, the kernel supports the 64-bit EFI handoff entry point
given at handover_offset + 0x200.
+ Bit 4 (read): XLF_EFI_KEXEC
+ - If 1, the kernel supports kexec EFI boot with EFI runtime support.
+
Field name: cmdline_size
Type: read
Offset/size: 0x238/4
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 9ec06a1..ec3b8ba 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -391,7 +391,14 @@ xloadflags:
#else
# define XLF23 0
#endif
- .word XLF0 | XLF1 | XLF23
+
+#if defined(CONFIG_X86_64) && defined(CONFIG_EFI) && defined(CONFIG_KEXEC)
+# define XLF4 XLF_EFI_KEXEC
+#else
+# define XLF4 0
+#endif
+
+ .word XLF0 | XLF1 | XLF23 | XLF4
cmdline_size: .long COMMAND_LINE_SIZE-1 #length of the command line,
#added with boot protocol
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 64fe421..225b098 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -24,6 +24,7 @@
#define XLF_CAN_BE_LOADED_ABOVE_4G (1<<1)
#define XLF_EFI_HANDOVER_32 (1<<2)
#define XLF_EFI_HANDOVER_64 (1<<3)
+#define XLF_EFI_KEXEC (1<<4)
#ifndef __ASSEMBLY__
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 11/14] x86: add xloadflags bit for efi runtime support on kexec
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
Old kexec-tools can not load new kernel. The reason is kexec-tools do not fill
efi_info in x86 setup header previously, thus efi failed to initialize.
In new kexec-tools it will by default fill efi_info and pass other efi required
infomation to 2nd kernel so kexec kernel efi initialization can succeed finally.
To prevent from breaking userspace, add a new xloadflags bit so kexec-tools
can check the flag and switch to old logic.
changelog:
Matt: +&& defined(CONFIG_KEXEC)
improve patch description.
HPA: document the flag.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
---
Documentation/x86/boot.txt | 3 +++
| 9 ++++++++-
arch/x86/include/uapi/asm/bootparam.h | 1 +
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index f4f268c..cb81741d 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -608,6 +608,9 @@ Protocol: 2.12+
- If 1, the kernel supports the 64-bit EFI handoff entry point
given at handover_offset + 0x200.
+ Bit 4 (read): XLF_EFI_KEXEC
+ - If 1, the kernel supports kexec EFI boot with EFI runtime support.
+
Field name: cmdline_size
Type: read
Offset/size: 0x238/4
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 9ec06a1..ec3b8ba 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -391,7 +391,14 @@ xloadflags:
#else
# define XLF23 0
#endif
- .word XLF0 | XLF1 | XLF23
+
+#if defined(CONFIG_X86_64) && defined(CONFIG_EFI) && defined(CONFIG_KEXEC)
+# define XLF4 XLF_EFI_KEXEC
+#else
+# define XLF4 0
+#endif
+
+ .word XLF0 | XLF1 | XLF23 | XLF4
cmdline_size: .long COMMAND_LINE_SIZE-1 #length of the command line,
#added with boot protocol
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 64fe421..225b098 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -24,6 +24,7 @@
#define XLF_CAN_BE_LOADED_ABOVE_4G (1<<1)
#define XLF_EFI_HANDOVER_32 (1<<2)
#define XLF_EFI_HANDOVER_64 (1<<3)
+#define XLF_EFI_KEXEC (1<<4)
#ifndef __ASSEMBLY__
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 11/14] x86: add xloadflags bit for efi runtime support on kexec
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
Old kexec-tools can not load new kernel. The reason is kexec-tools do not fill
efi_info in x86 setup header previously, thus efi failed to initialize.
In new kexec-tools it will by default fill efi_info and pass other efi required
infomation to 2nd kernel so kexec kernel efi initialization can succeed finally.
To prevent from breaking userspace, add a new xloadflags bit so kexec-tools
can check the flag and switch to old logic.
changelog:
Matt: +&& defined(CONFIG_KEXEC)
improve patch description.
HPA: document the flag.
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Acked-by: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>
---
Documentation/x86/boot.txt | 3 +++
| 9 ++++++++-
arch/x86/include/uapi/asm/bootparam.h | 1 +
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index f4f268c..cb81741d 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -608,6 +608,9 @@ Protocol: 2.12+
- If 1, the kernel supports the 64-bit EFI handoff entry point
given at handover_offset + 0x200.
+ Bit 4 (read): XLF_EFI_KEXEC
+ - If 1, the kernel supports kexec EFI boot with EFI runtime support.
+
Field name: cmdline_size
Type: read
Offset/size: 0x238/4
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 9ec06a1..ec3b8ba 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -391,7 +391,14 @@ xloadflags:
#else
# define XLF23 0
#endif
- .word XLF0 | XLF1 | XLF23
+
+#if defined(CONFIG_X86_64) && defined(CONFIG_EFI) && defined(CONFIG_KEXEC)
+# define XLF4 XLF_EFI_KEXEC
+#else
+# define XLF4 0
+#endif
+
+ .word XLF0 | XLF1 | XLF23 | XLF4
cmdline_size: .long COMMAND_LINE_SIZE-1 #length of the command line,
#added with boot protocol
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 64fe421..225b098 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -24,6 +24,7 @@
#define XLF_CAN_BE_LOADED_ABOVE_4G (1<<1)
#define XLF_EFI_HANDOVER_32 (1<<2)
#define XLF_EFI_HANDOVER_64 (1<<3)
+#define XLF_EFI_KEXEC (1<<4)
#ifndef __ASSEMBLY__
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH v5 12/14] x86: export x86 boot_params to sysfs
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
the kexec kernel efi runtime support also need read the old efi_info from
boot_params. Currently it exists in debugfs which is not a good place for
such infomation. Per HPA, we should avoid of "sploit debugfs".
In this patch /sys/kernel/boot_params are exported, also the setup_data is
exported as a subdirectory. kexec-tools is using debugfs for hardware_subarch
for a long time now so we're not removing it yet.
Structure is like below:
/sys/kernel/boot_params
|__ data /* boot_params in binary*/
|__ setup_data
| |__ 0 /* the first setup_data node */
| | |__ data /* setup_data node 0 in binary*/
| | |__ type /* setup_data type of setup_data node 0, hex string */
[snip]
|__ version /* boot protocal version (in hex, "0x" prefixed)*/
Changelog:
Greg: use __ATTR_RO() and group attr.
Matt and Boris: Documentation improvement, code indentation.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
Documentation/ABI/testing/sysfs-kernel-boot_params | 39 +++
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/ksysfs.c | 339 +++++++++++++++++++++
3 files changed, 379 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-kernel-boot_params
create mode 100644 arch/x86/kernel/ksysfs.c
diff --git a/Documentation/ABI/testing/sysfs-kernel-boot_params b/Documentation/ABI/testing/sysfs-kernel-boot_params
new file mode 100644
index 0000000..26cc0e8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-boot_params
@@ -0,0 +1,39 @@
+What: /sys/kernel/boot_params
+Date: December 2013
+Contact: Dave Young <dyoung@redhat.com>
+Description:
+ The /sys/kernel/boot_params directory contains two
+ files: "data" and "version" and one subdirectory "setup_data".
+ It is used to export the kernel boot parameters of an x86
+ platform to userspace for kexec and debugging purpose.
+
+ If there's no setup_data in boot_params the subdirectory will
+ not be created.
+
+ "data" file is the binary representation of struct boot_params.
+
+ "version" file is the string representation of boot
+ protocol version.
+
+ "setup_data" subdirectory contains the setup_data data
+ structure in boot_params. setup_data is maintained in kernel
+ as a link list. In "setup_data" subdirectory there's one
+ subdirectory for each link list node named with the number
+ of the list nodes. The list node subdirectory contains two
+ files "type" and "data". "type" file is the string
+ representation of setup_data type. "data" file is the binary
+ representation of setup_data payload.
+
+ The whole boot_params directory structure is like below:
+ /sys/kernel/boot_params
+ |__ data
+ |__ setup_data
+ | |__ 0
+ | | |__ data
+ | | |__ type
+ | |__ 1
+ | |__ data
+ | |__ type
+ |__ version
+
+Users: Kexec
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 9b0a34e..510cca5 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o
obj-y += syscall_$(BITS).o
obj-$(CONFIG_X86_64) += vsyscall_64.o
obj-$(CONFIG_X86_64) += vsyscall_emu_64.o
+obj-$(CONFIG_SYSFS) += ksysfs.o
obj-y += bootflag.o e820.o
obj-y += pci-dma.o quirks.o topology.o kdebugfs.o
obj-y += alternative.o i8253.o pci-nommu.o hw_breakpoint.o
diff --git a/arch/x86/kernel/ksysfs.c b/arch/x86/kernel/ksysfs.c
new file mode 100644
index 0000000..eb53d15
--- /dev/null
+++ b/arch/x86/kernel/ksysfs.c
@@ -0,0 +1,339 @@
+/*
+ * Architecture specific sysfs attributes in /sys/kernel
+ *
+ * Copyright (C) 2007, Intel Corp.
+ * Huang Ying <ying.huang@intel.com>
+ * Copyright (C) 2013, 2013 Red Hat, Inc.
+ * Dave Young <dyoung@redhat.com>
+ *
+ * This file is released under the GPLv2
+ */
+
+#include <linux/kobject.h>
+#include <linux/string.h>
+#include <linux/sysfs.h>
+#include <linux/init.h>
+#include <linux/stat.h>
+#include <linux/slab.h>
+#include <linux/mm.h>
+
+#include <asm/setup.h>
+
+static ssize_t version_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return sprintf(buf, "0x%04x\n", boot_params.hdr.version);
+}
+
+static struct kobj_attribute boot_params_version_attr = __ATTR_RO(version);
+
+static ssize_t boot_params_data_read(struct file *fp, struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t off, size_t count)
+{
+ memcpy(buf, (void *)&boot_params + off, count);
+ return count;
+}
+
+static struct bin_attribute boot_params_data_attr = {
+ .attr = {
+ .name = "data",
+ .mode = S_IRUGO,
+ },
+ .read = boot_params_data_read,
+ .size = sizeof(boot_params),
+};
+
+static struct attribute *boot_params_version_attrs[] = {
+ &boot_params_version_attr.attr,
+ NULL,
+};
+
+static struct bin_attribute *boot_params_data_attrs[] = {
+ &boot_params_data_attr,
+ NULL,
+};
+
+static struct attribute_group boot_params_attr_group = {
+ .attrs = boot_params_version_attrs,
+ .bin_attrs = boot_params_data_attrs,
+};
+
+static int kobj_to_setup_data_nr(struct kobject *kobj, int *nr)
+{
+ const char *name;
+
+ name = kobject_name(kobj);
+ return kstrtoint(name, 10, nr);
+}
+
+static int get_setup_data_paddr(int nr, u64 *paddr)
+{
+ int i = 0;
+ struct setup_data *data;
+ u64 pa_data = boot_params.hdr.setup_data;
+
+ while (pa_data) {
+ if (nr == i) {
+ *paddr = pa_data;
+ return 0;
+ }
+ data = ioremap_cache(pa_data, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+
+ pa_data = data->next;
+ iounmap(data);
+ i++;
+ }
+ return -EINVAL;
+}
+
+static int __init get_setup_data_size(int nr, size_t *size)
+{
+ int i = 0;
+ struct setup_data *data;
+ u64 pa_data = boot_params.hdr.setup_data;
+
+ while (pa_data) {
+ data = ioremap_cache(pa_data, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+ if (nr == i) {
+ *size = data->len;
+ iounmap(data);
+ return 0;
+ }
+
+ pa_data = data->next;
+ iounmap(data);
+ i++;
+ }
+ return -EINVAL;
+}
+
+static ssize_t type_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ int nr, ret;
+ u64 paddr;
+ struct setup_data *data;
+
+ ret = kobj_to_setup_data_nr(kobj, &nr);
+ if (ret)
+ return ret;
+
+ ret = get_setup_data_paddr(nr, &paddr);
+ if (ret)
+ return ret;
+ data = ioremap_cache(paddr, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+
+ ret = sprintf(buf, "0x%x\n", data->type);
+ iounmap(data);
+ return ret;
+}
+
+static ssize_t setup_data_data_read(struct file *fp,
+ struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf,
+ loff_t off, size_t count)
+{
+ int nr, ret = 0;
+ u64 paddr;
+ struct setup_data *data;
+ void *p;
+
+ ret = kobj_to_setup_data_nr(kobj, &nr);
+ if (ret)
+ return ret;
+
+ ret = get_setup_data_paddr(nr, &paddr);
+ if (ret)
+ return ret;
+ data = ioremap_cache(paddr, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+
+ if (off > data->len) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (count > data->len - off)
+ count = data->len - off;
+
+ if (!count)
+ goto out;
+
+ ret = count;
+ p = ioremap_cache(paddr + sizeof(*data), data->len);
+ if (!p) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ memcpy(buf, p + off, count);
+ iounmap(p);
+out:
+ iounmap(data);
+ return ret;
+}
+
+static struct kobj_attribute type_attr = __ATTR_RO(type);
+
+static struct bin_attribute data_attr = {
+ .attr = {
+ .name = "data",
+ .mode = S_IRUGO,
+ },
+ .read = setup_data_data_read,
+};
+
+static struct attribute *setup_data_type_attrs[] = {
+ &type_attr.attr,
+ NULL,
+};
+
+static struct bin_attribute *setup_data_data_attrs[] = {
+ &data_attr,
+ NULL,
+};
+
+static struct attribute_group setup_data_attr_group = {
+ .attrs = setup_data_type_attrs,
+ .bin_attrs = setup_data_data_attrs,
+};
+
+static int __init create_setup_data_node(struct kobject *parent,
+ struct kobject **kobjp, int nr)
+{
+ int ret = 0;
+ size_t size;
+ struct kobject *kobj;
+ char name[16]; /* should be enough for setup_data nodes numbers */
+ snprintf(name, 16, "%d", nr);
+
+ kobj = kobject_create_and_add(name, parent);
+ if (!kobj)
+ return -ENOMEM;
+
+ ret = get_setup_data_size(nr, &size);
+ if (ret)
+ goto out_kobj;
+
+ data_attr.size = size;
+ ret = sysfs_create_group(kobj, &setup_data_attr_group);
+ if (ret)
+ goto out_kobj;
+ *kobjp = kobj;
+
+ return 0;
+out_kobj:
+ kobject_put(kobj);
+ return ret;
+}
+
+static void __init cleanup_setup_data_node(struct kobject *kobj)
+{
+ sysfs_remove_group(kobj, &setup_data_attr_group);
+ kobject_put(kobj);
+}
+
+static int __init get_setup_data_total_num(u64 pa_data, int *nr)
+{
+ int ret = 0;
+ struct setup_data *data;
+
+ *nr = 0;
+ while (pa_data) {
+ *nr += 1;
+ data = ioremap_cache(pa_data, sizeof(*data));
+ if (!data) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ pa_data = data->next;
+ iounmap(data);
+ }
+
+out:
+ return ret;
+}
+
+static int __init create_setup_data_nodes(struct kobject *parent)
+{
+ struct kobject *setup_data_kobj, **kobjp;
+ u64 pa_data;
+ int i, j, nr, ret = 0;
+
+ pa_data = boot_params.hdr.setup_data;
+ if (!pa_data)
+ return 0;
+
+ setup_data_kobj = kobject_create_and_add("setup_data", parent);
+ if (!setup_data_kobj) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ret = get_setup_data_total_num(pa_data, &nr);
+ if (ret)
+ goto out_setup_data_kobj;
+
+ kobjp = kmalloc(sizeof(*kobjp) * nr, GFP_KERNEL);
+ if (!kobjp) {
+ ret = -ENOMEM;
+ goto out_setup_data_kobj;
+ }
+
+ for (i = 0; i < nr; i++) {
+ ret = create_setup_data_node(setup_data_kobj, kobjp + i, i);
+ if (ret)
+ goto out_clean_nodes;
+ }
+
+ kfree(kobjp);
+ return 0;
+
+out_clean_nodes:
+ for (j = i - 1; j > 0; j--)
+ cleanup_setup_data_node(*(kobjp + j));
+ kfree(kobjp);
+out_setup_data_kobj:
+ kobject_put(setup_data_kobj);
+out:
+ return ret;
+}
+
+static int __init boot_params_ksysfs_init(void)
+{
+ int ret;
+ struct kobject *boot_params_kobj;
+
+ boot_params_kobj = kobject_create_and_add("boot_params",
+ kernel_kobj);
+ if (!boot_params_kobj) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ret = sysfs_create_group(boot_params_kobj, &boot_params_attr_group);
+ if (ret)
+ goto out_boot_params_kobj;
+
+ ret = create_setup_data_nodes(boot_params_kobj);
+ if (ret)
+ goto out_create_group;
+
+ return 0;
+out_create_group:
+ sysfs_remove_group(boot_params_kobj, &boot_params_attr_group);
+out_boot_params_kobj:
+ kobject_put(boot_params_kobj);
+out:
+ return ret;
+}
+
+arch_initcall(boot_params_ksysfs_init);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 12/14] x86: export x86 boot_params to sysfs
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
the kexec kernel efi runtime support also need read the old efi_info from
boot_params. Currently it exists in debugfs which is not a good place for
such infomation. Per HPA, we should avoid of "sploit debugfs".
In this patch /sys/kernel/boot_params are exported, also the setup_data is
exported as a subdirectory. kexec-tools is using debugfs for hardware_subarch
for a long time now so we're not removing it yet.
Structure is like below:
/sys/kernel/boot_params
|__ data /* boot_params in binary*/
|__ setup_data
| |__ 0 /* the first setup_data node */
| | |__ data /* setup_data node 0 in binary*/
| | |__ type /* setup_data type of setup_data node 0, hex string */
[snip]
|__ version /* boot protocal version (in hex, "0x" prefixed)*/
Changelog:
Greg: use __ATTR_RO() and group attr.
Matt and Boris: Documentation improvement, code indentation.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
Documentation/ABI/testing/sysfs-kernel-boot_params | 39 +++
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/ksysfs.c | 339 +++++++++++++++++++++
3 files changed, 379 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-kernel-boot_params
create mode 100644 arch/x86/kernel/ksysfs.c
diff --git a/Documentation/ABI/testing/sysfs-kernel-boot_params b/Documentation/ABI/testing/sysfs-kernel-boot_params
new file mode 100644
index 0000000..26cc0e8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-boot_params
@@ -0,0 +1,39 @@
+What: /sys/kernel/boot_params
+Date: December 2013
+Contact: Dave Young <dyoung@redhat.com>
+Description:
+ The /sys/kernel/boot_params directory contains two
+ files: "data" and "version" and one subdirectory "setup_data".
+ It is used to export the kernel boot parameters of an x86
+ platform to userspace for kexec and debugging purpose.
+
+ If there's no setup_data in boot_params the subdirectory will
+ not be created.
+
+ "data" file is the binary representation of struct boot_params.
+
+ "version" file is the string representation of boot
+ protocol version.
+
+ "setup_data" subdirectory contains the setup_data data
+ structure in boot_params. setup_data is maintained in kernel
+ as a link list. In "setup_data" subdirectory there's one
+ subdirectory for each link list node named with the number
+ of the list nodes. The list node subdirectory contains two
+ files "type" and "data". "type" file is the string
+ representation of setup_data type. "data" file is the binary
+ representation of setup_data payload.
+
+ The whole boot_params directory structure is like below:
+ /sys/kernel/boot_params
+ |__ data
+ |__ setup_data
+ | |__ 0
+ | | |__ data
+ | | |__ type
+ | |__ 1
+ | |__ data
+ | |__ type
+ |__ version
+
+Users: Kexec
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 9b0a34e..510cca5 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o
obj-y += syscall_$(BITS).o
obj-$(CONFIG_X86_64) += vsyscall_64.o
obj-$(CONFIG_X86_64) += vsyscall_emu_64.o
+obj-$(CONFIG_SYSFS) += ksysfs.o
obj-y += bootflag.o e820.o
obj-y += pci-dma.o quirks.o topology.o kdebugfs.o
obj-y += alternative.o i8253.o pci-nommu.o hw_breakpoint.o
diff --git a/arch/x86/kernel/ksysfs.c b/arch/x86/kernel/ksysfs.c
new file mode 100644
index 0000000..eb53d15
--- /dev/null
+++ b/arch/x86/kernel/ksysfs.c
@@ -0,0 +1,339 @@
+/*
+ * Architecture specific sysfs attributes in /sys/kernel
+ *
+ * Copyright (C) 2007, Intel Corp.
+ * Huang Ying <ying.huang@intel.com>
+ * Copyright (C) 2013, 2013 Red Hat, Inc.
+ * Dave Young <dyoung@redhat.com>
+ *
+ * This file is released under the GPLv2
+ */
+
+#include <linux/kobject.h>
+#include <linux/string.h>
+#include <linux/sysfs.h>
+#include <linux/init.h>
+#include <linux/stat.h>
+#include <linux/slab.h>
+#include <linux/mm.h>
+
+#include <asm/setup.h>
+
+static ssize_t version_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return sprintf(buf, "0x%04x\n", boot_params.hdr.version);
+}
+
+static struct kobj_attribute boot_params_version_attr = __ATTR_RO(version);
+
+static ssize_t boot_params_data_read(struct file *fp, struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t off, size_t count)
+{
+ memcpy(buf, (void *)&boot_params + off, count);
+ return count;
+}
+
+static struct bin_attribute boot_params_data_attr = {
+ .attr = {
+ .name = "data",
+ .mode = S_IRUGO,
+ },
+ .read = boot_params_data_read,
+ .size = sizeof(boot_params),
+};
+
+static struct attribute *boot_params_version_attrs[] = {
+ &boot_params_version_attr.attr,
+ NULL,
+};
+
+static struct bin_attribute *boot_params_data_attrs[] = {
+ &boot_params_data_attr,
+ NULL,
+};
+
+static struct attribute_group boot_params_attr_group = {
+ .attrs = boot_params_version_attrs,
+ .bin_attrs = boot_params_data_attrs,
+};
+
+static int kobj_to_setup_data_nr(struct kobject *kobj, int *nr)
+{
+ const char *name;
+
+ name = kobject_name(kobj);
+ return kstrtoint(name, 10, nr);
+}
+
+static int get_setup_data_paddr(int nr, u64 *paddr)
+{
+ int i = 0;
+ struct setup_data *data;
+ u64 pa_data = boot_params.hdr.setup_data;
+
+ while (pa_data) {
+ if (nr == i) {
+ *paddr = pa_data;
+ return 0;
+ }
+ data = ioremap_cache(pa_data, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+
+ pa_data = data->next;
+ iounmap(data);
+ i++;
+ }
+ return -EINVAL;
+}
+
+static int __init get_setup_data_size(int nr, size_t *size)
+{
+ int i = 0;
+ struct setup_data *data;
+ u64 pa_data = boot_params.hdr.setup_data;
+
+ while (pa_data) {
+ data = ioremap_cache(pa_data, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+ if (nr == i) {
+ *size = data->len;
+ iounmap(data);
+ return 0;
+ }
+
+ pa_data = data->next;
+ iounmap(data);
+ i++;
+ }
+ return -EINVAL;
+}
+
+static ssize_t type_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ int nr, ret;
+ u64 paddr;
+ struct setup_data *data;
+
+ ret = kobj_to_setup_data_nr(kobj, &nr);
+ if (ret)
+ return ret;
+
+ ret = get_setup_data_paddr(nr, &paddr);
+ if (ret)
+ return ret;
+ data = ioremap_cache(paddr, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+
+ ret = sprintf(buf, "0x%x\n", data->type);
+ iounmap(data);
+ return ret;
+}
+
+static ssize_t setup_data_data_read(struct file *fp,
+ struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf,
+ loff_t off, size_t count)
+{
+ int nr, ret = 0;
+ u64 paddr;
+ struct setup_data *data;
+ void *p;
+
+ ret = kobj_to_setup_data_nr(kobj, &nr);
+ if (ret)
+ return ret;
+
+ ret = get_setup_data_paddr(nr, &paddr);
+ if (ret)
+ return ret;
+ data = ioremap_cache(paddr, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+
+ if (off > data->len) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (count > data->len - off)
+ count = data->len - off;
+
+ if (!count)
+ goto out;
+
+ ret = count;
+ p = ioremap_cache(paddr + sizeof(*data), data->len);
+ if (!p) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ memcpy(buf, p + off, count);
+ iounmap(p);
+out:
+ iounmap(data);
+ return ret;
+}
+
+static struct kobj_attribute type_attr = __ATTR_RO(type);
+
+static struct bin_attribute data_attr = {
+ .attr = {
+ .name = "data",
+ .mode = S_IRUGO,
+ },
+ .read = setup_data_data_read,
+};
+
+static struct attribute *setup_data_type_attrs[] = {
+ &type_attr.attr,
+ NULL,
+};
+
+static struct bin_attribute *setup_data_data_attrs[] = {
+ &data_attr,
+ NULL,
+};
+
+static struct attribute_group setup_data_attr_group = {
+ .attrs = setup_data_type_attrs,
+ .bin_attrs = setup_data_data_attrs,
+};
+
+static int __init create_setup_data_node(struct kobject *parent,
+ struct kobject **kobjp, int nr)
+{
+ int ret = 0;
+ size_t size;
+ struct kobject *kobj;
+ char name[16]; /* should be enough for setup_data nodes numbers */
+ snprintf(name, 16, "%d", nr);
+
+ kobj = kobject_create_and_add(name, parent);
+ if (!kobj)
+ return -ENOMEM;
+
+ ret = get_setup_data_size(nr, &size);
+ if (ret)
+ goto out_kobj;
+
+ data_attr.size = size;
+ ret = sysfs_create_group(kobj, &setup_data_attr_group);
+ if (ret)
+ goto out_kobj;
+ *kobjp = kobj;
+
+ return 0;
+out_kobj:
+ kobject_put(kobj);
+ return ret;
+}
+
+static void __init cleanup_setup_data_node(struct kobject *kobj)
+{
+ sysfs_remove_group(kobj, &setup_data_attr_group);
+ kobject_put(kobj);
+}
+
+static int __init get_setup_data_total_num(u64 pa_data, int *nr)
+{
+ int ret = 0;
+ struct setup_data *data;
+
+ *nr = 0;
+ while (pa_data) {
+ *nr += 1;
+ data = ioremap_cache(pa_data, sizeof(*data));
+ if (!data) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ pa_data = data->next;
+ iounmap(data);
+ }
+
+out:
+ return ret;
+}
+
+static int __init create_setup_data_nodes(struct kobject *parent)
+{
+ struct kobject *setup_data_kobj, **kobjp;
+ u64 pa_data;
+ int i, j, nr, ret = 0;
+
+ pa_data = boot_params.hdr.setup_data;
+ if (!pa_data)
+ return 0;
+
+ setup_data_kobj = kobject_create_and_add("setup_data", parent);
+ if (!setup_data_kobj) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ret = get_setup_data_total_num(pa_data, &nr);
+ if (ret)
+ goto out_setup_data_kobj;
+
+ kobjp = kmalloc(sizeof(*kobjp) * nr, GFP_KERNEL);
+ if (!kobjp) {
+ ret = -ENOMEM;
+ goto out_setup_data_kobj;
+ }
+
+ for (i = 0; i < nr; i++) {
+ ret = create_setup_data_node(setup_data_kobj, kobjp + i, i);
+ if (ret)
+ goto out_clean_nodes;
+ }
+
+ kfree(kobjp);
+ return 0;
+
+out_clean_nodes:
+ for (j = i - 1; j > 0; j--)
+ cleanup_setup_data_node(*(kobjp + j));
+ kfree(kobjp);
+out_setup_data_kobj:
+ kobject_put(setup_data_kobj);
+out:
+ return ret;
+}
+
+static int __init boot_params_ksysfs_init(void)
+{
+ int ret;
+ struct kobject *boot_params_kobj;
+
+ boot_params_kobj = kobject_create_and_add("boot_params",
+ kernel_kobj);
+ if (!boot_params_kobj) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ret = sysfs_create_group(boot_params_kobj, &boot_params_attr_group);
+ if (ret)
+ goto out_boot_params_kobj;
+
+ ret = create_setup_data_nodes(boot_params_kobj);
+ if (ret)
+ goto out_create_group;
+
+ return 0;
+out_create_group:
+ sysfs_remove_group(boot_params_kobj, &boot_params_attr_group);
+out_boot_params_kobj:
+ kobject_put(boot_params_kobj);
+out:
+ return ret;
+}
+
+arch_initcall(boot_params_ksysfs_init);
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 12/14] x86: export x86 boot_params to sysfs
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
the kexec kernel efi runtime support also need read the old efi_info from
boot_params. Currently it exists in debugfs which is not a good place for
such infomation. Per HPA, we should avoid of "sploit debugfs".
In this patch /sys/kernel/boot_params are exported, also the setup_data is
exported as a subdirectory. kexec-tools is using debugfs for hardware_subarch
for a long time now so we're not removing it yet.
Structure is like below:
/sys/kernel/boot_params
|__ data /* boot_params in binary*/
|__ setup_data
| |__ 0 /* the first setup_data node */
| | |__ data /* setup_data node 0 in binary*/
| | |__ type /* setup_data type of setup_data node 0, hex string */
[snip]
|__ version /* boot protocal version (in hex, "0x" prefixed)*/
Changelog:
Greg: use __ATTR_RO() and group attr.
Matt and Boris: Documentation improvement, code indentation.
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
Documentation/ABI/testing/sysfs-kernel-boot_params | 39 +++
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/ksysfs.c | 339 +++++++++++++++++++++
3 files changed, 379 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-kernel-boot_params
create mode 100644 arch/x86/kernel/ksysfs.c
diff --git a/Documentation/ABI/testing/sysfs-kernel-boot_params b/Documentation/ABI/testing/sysfs-kernel-boot_params
new file mode 100644
index 0000000..26cc0e8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-boot_params
@@ -0,0 +1,39 @@
+What: /sys/kernel/boot_params
+Date: December 2013
+Contact: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
+Description:
+ The /sys/kernel/boot_params directory contains two
+ files: "data" and "version" and one subdirectory "setup_data".
+ It is used to export the kernel boot parameters of an x86
+ platform to userspace for kexec and debugging purpose.
+
+ If there's no setup_data in boot_params the subdirectory will
+ not be created.
+
+ "data" file is the binary representation of struct boot_params.
+
+ "version" file is the string representation of boot
+ protocol version.
+
+ "setup_data" subdirectory contains the setup_data data
+ structure in boot_params. setup_data is maintained in kernel
+ as a link list. In "setup_data" subdirectory there's one
+ subdirectory for each link list node named with the number
+ of the list nodes. The list node subdirectory contains two
+ files "type" and "data". "type" file is the string
+ representation of setup_data type. "data" file is the binary
+ representation of setup_data payload.
+
+ The whole boot_params directory structure is like below:
+ /sys/kernel/boot_params
+ |__ data
+ |__ setup_data
+ | |__ 0
+ | | |__ data
+ | | |__ type
+ | |__ 1
+ | |__ data
+ | |__ type
+ |__ version
+
+Users: Kexec
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 9b0a34e..510cca5 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o
obj-y += syscall_$(BITS).o
obj-$(CONFIG_X86_64) += vsyscall_64.o
obj-$(CONFIG_X86_64) += vsyscall_emu_64.o
+obj-$(CONFIG_SYSFS) += ksysfs.o
obj-y += bootflag.o e820.o
obj-y += pci-dma.o quirks.o topology.o kdebugfs.o
obj-y += alternative.o i8253.o pci-nommu.o hw_breakpoint.o
diff --git a/arch/x86/kernel/ksysfs.c b/arch/x86/kernel/ksysfs.c
new file mode 100644
index 0000000..eb53d15
--- /dev/null
+++ b/arch/x86/kernel/ksysfs.c
@@ -0,0 +1,339 @@
+/*
+ * Architecture specific sysfs attributes in /sys/kernel
+ *
+ * Copyright (C) 2007, Intel Corp.
+ * Huang Ying <ying.huang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
+ * Copyright (C) 2013, 2013 Red Hat, Inc.
+ * Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
+ *
+ * This file is released under the GPLv2
+ */
+
+#include <linux/kobject.h>
+#include <linux/string.h>
+#include <linux/sysfs.h>
+#include <linux/init.h>
+#include <linux/stat.h>
+#include <linux/slab.h>
+#include <linux/mm.h>
+
+#include <asm/setup.h>
+
+static ssize_t version_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return sprintf(buf, "0x%04x\n", boot_params.hdr.version);
+}
+
+static struct kobj_attribute boot_params_version_attr = __ATTR_RO(version);
+
+static ssize_t boot_params_data_read(struct file *fp, struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t off, size_t count)
+{
+ memcpy(buf, (void *)&boot_params + off, count);
+ return count;
+}
+
+static struct bin_attribute boot_params_data_attr = {
+ .attr = {
+ .name = "data",
+ .mode = S_IRUGO,
+ },
+ .read = boot_params_data_read,
+ .size = sizeof(boot_params),
+};
+
+static struct attribute *boot_params_version_attrs[] = {
+ &boot_params_version_attr.attr,
+ NULL,
+};
+
+static struct bin_attribute *boot_params_data_attrs[] = {
+ &boot_params_data_attr,
+ NULL,
+};
+
+static struct attribute_group boot_params_attr_group = {
+ .attrs = boot_params_version_attrs,
+ .bin_attrs = boot_params_data_attrs,
+};
+
+static int kobj_to_setup_data_nr(struct kobject *kobj, int *nr)
+{
+ const char *name;
+
+ name = kobject_name(kobj);
+ return kstrtoint(name, 10, nr);
+}
+
+static int get_setup_data_paddr(int nr, u64 *paddr)
+{
+ int i = 0;
+ struct setup_data *data;
+ u64 pa_data = boot_params.hdr.setup_data;
+
+ while (pa_data) {
+ if (nr == i) {
+ *paddr = pa_data;
+ return 0;
+ }
+ data = ioremap_cache(pa_data, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+
+ pa_data = data->next;
+ iounmap(data);
+ i++;
+ }
+ return -EINVAL;
+}
+
+static int __init get_setup_data_size(int nr, size_t *size)
+{
+ int i = 0;
+ struct setup_data *data;
+ u64 pa_data = boot_params.hdr.setup_data;
+
+ while (pa_data) {
+ data = ioremap_cache(pa_data, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+ if (nr == i) {
+ *size = data->len;
+ iounmap(data);
+ return 0;
+ }
+
+ pa_data = data->next;
+ iounmap(data);
+ i++;
+ }
+ return -EINVAL;
+}
+
+static ssize_t type_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ int nr, ret;
+ u64 paddr;
+ struct setup_data *data;
+
+ ret = kobj_to_setup_data_nr(kobj, &nr);
+ if (ret)
+ return ret;
+
+ ret = get_setup_data_paddr(nr, &paddr);
+ if (ret)
+ return ret;
+ data = ioremap_cache(paddr, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+
+ ret = sprintf(buf, "0x%x\n", data->type);
+ iounmap(data);
+ return ret;
+}
+
+static ssize_t setup_data_data_read(struct file *fp,
+ struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf,
+ loff_t off, size_t count)
+{
+ int nr, ret = 0;
+ u64 paddr;
+ struct setup_data *data;
+ void *p;
+
+ ret = kobj_to_setup_data_nr(kobj, &nr);
+ if (ret)
+ return ret;
+
+ ret = get_setup_data_paddr(nr, &paddr);
+ if (ret)
+ return ret;
+ data = ioremap_cache(paddr, sizeof(*data));
+ if (!data)
+ return -ENOMEM;
+
+ if (off > data->len) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (count > data->len - off)
+ count = data->len - off;
+
+ if (!count)
+ goto out;
+
+ ret = count;
+ p = ioremap_cache(paddr + sizeof(*data), data->len);
+ if (!p) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ memcpy(buf, p + off, count);
+ iounmap(p);
+out:
+ iounmap(data);
+ return ret;
+}
+
+static struct kobj_attribute type_attr = __ATTR_RO(type);
+
+static struct bin_attribute data_attr = {
+ .attr = {
+ .name = "data",
+ .mode = S_IRUGO,
+ },
+ .read = setup_data_data_read,
+};
+
+static struct attribute *setup_data_type_attrs[] = {
+ &type_attr.attr,
+ NULL,
+};
+
+static struct bin_attribute *setup_data_data_attrs[] = {
+ &data_attr,
+ NULL,
+};
+
+static struct attribute_group setup_data_attr_group = {
+ .attrs = setup_data_type_attrs,
+ .bin_attrs = setup_data_data_attrs,
+};
+
+static int __init create_setup_data_node(struct kobject *parent,
+ struct kobject **kobjp, int nr)
+{
+ int ret = 0;
+ size_t size;
+ struct kobject *kobj;
+ char name[16]; /* should be enough for setup_data nodes numbers */
+ snprintf(name, 16, "%d", nr);
+
+ kobj = kobject_create_and_add(name, parent);
+ if (!kobj)
+ return -ENOMEM;
+
+ ret = get_setup_data_size(nr, &size);
+ if (ret)
+ goto out_kobj;
+
+ data_attr.size = size;
+ ret = sysfs_create_group(kobj, &setup_data_attr_group);
+ if (ret)
+ goto out_kobj;
+ *kobjp = kobj;
+
+ return 0;
+out_kobj:
+ kobject_put(kobj);
+ return ret;
+}
+
+static void __init cleanup_setup_data_node(struct kobject *kobj)
+{
+ sysfs_remove_group(kobj, &setup_data_attr_group);
+ kobject_put(kobj);
+}
+
+static int __init get_setup_data_total_num(u64 pa_data, int *nr)
+{
+ int ret = 0;
+ struct setup_data *data;
+
+ *nr = 0;
+ while (pa_data) {
+ *nr += 1;
+ data = ioremap_cache(pa_data, sizeof(*data));
+ if (!data) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ pa_data = data->next;
+ iounmap(data);
+ }
+
+out:
+ return ret;
+}
+
+static int __init create_setup_data_nodes(struct kobject *parent)
+{
+ struct kobject *setup_data_kobj, **kobjp;
+ u64 pa_data;
+ int i, j, nr, ret = 0;
+
+ pa_data = boot_params.hdr.setup_data;
+ if (!pa_data)
+ return 0;
+
+ setup_data_kobj = kobject_create_and_add("setup_data", parent);
+ if (!setup_data_kobj) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ret = get_setup_data_total_num(pa_data, &nr);
+ if (ret)
+ goto out_setup_data_kobj;
+
+ kobjp = kmalloc(sizeof(*kobjp) * nr, GFP_KERNEL);
+ if (!kobjp) {
+ ret = -ENOMEM;
+ goto out_setup_data_kobj;
+ }
+
+ for (i = 0; i < nr; i++) {
+ ret = create_setup_data_node(setup_data_kobj, kobjp + i, i);
+ if (ret)
+ goto out_clean_nodes;
+ }
+
+ kfree(kobjp);
+ return 0;
+
+out_clean_nodes:
+ for (j = i - 1; j > 0; j--)
+ cleanup_setup_data_node(*(kobjp + j));
+ kfree(kobjp);
+out_setup_data_kobj:
+ kobject_put(setup_data_kobj);
+out:
+ return ret;
+}
+
+static int __init boot_params_ksysfs_init(void)
+{
+ int ret;
+ struct kobject *boot_params_kobj;
+
+ boot_params_kobj = kobject_create_and_add("boot_params",
+ kernel_kobj);
+ if (!boot_params_kobj) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ret = sysfs_create_group(boot_params_kobj, &boot_params_attr_group);
+ if (ret)
+ goto out_boot_params_kobj;
+
+ ret = create_setup_data_nodes(boot_params_kobj);
+ if (ret)
+ goto out_create_group;
+
+ return 0;
+out_create_group:
+ sysfs_remove_group(boot_params_kobj, &boot_params_attr_group);
+out_boot_params_kobj:
+ kobject_put(boot_params_kobj);
+out:
+ return ret;
+}
+
+arch_initcall(boot_params_ksysfs_init);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH v5 12/14] x86: export x86 boot_params to sysfs
@ 2013-12-13 20:04 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-13 20:04 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On Mon, Dec 09, 2013 at 05:42:25PM +0800, Dave Young wrote:
> kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
> the kexec kernel efi runtime support also need read the old efi_info from
> boot_params. Currently it exists in debugfs which is not a good place for
> such infomation. Per HPA, we should avoid of "sploit debugfs".
>
> In this patch /sys/kernel/boot_params are exported, also the setup_data is
> exported as a subdirectory. kexec-tools is using debugfs for hardware_subarch
> for a long time now so we're not removing it yet.
>
> Structure is like below:
>
> /sys/kernel/boot_params
> |__ data /* boot_params in binary*/
> |__ setup_data
> | |__ 0 /* the first setup_data node */
> | | |__ data /* setup_data node 0 in binary*/
> | | |__ type /* setup_data type of setup_data node 0, hex string */
> [snip]
> |__ version /* boot protocal version (in hex, "0x" prefixed)*/
>
> Changelog:
> Greg: use __ATTR_RO() and group attr.
> Matt and Boris: Documentation improvement, code indentation.
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 12/14] x86: export x86 boot_params to sysfs
@ 2013-12-13 20:04 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-13 20:04 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On Mon, Dec 09, 2013 at 05:42:25PM +0800, Dave Young wrote:
> kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
> the kexec kernel efi runtime support also need read the old efi_info from
> boot_params. Currently it exists in debugfs which is not a good place for
> such infomation. Per HPA, we should avoid of "sploit debugfs".
>
> In this patch /sys/kernel/boot_params are exported, also the setup_data is
> exported as a subdirectory. kexec-tools is using debugfs for hardware_subarch
> for a long time now so we're not removing it yet.
>
> Structure is like below:
>
> /sys/kernel/boot_params
> |__ data /* boot_params in binary*/
> |__ setup_data
> | |__ 0 /* the first setup_data node */
> | | |__ data /* setup_data node 0 in binary*/
> | | |__ type /* setup_data type of setup_data node 0, hex string */
> [snip]
> |__ version /* boot protocal version (in hex, "0x" prefixed)*/
>
> Changelog:
> Greg: use __ATTR_RO() and group attr.
> Matt and Boris: Documentation improvement, code indentation.
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 12/14] x86: export x86 boot_params to sysfs
@ 2013-12-13 20:04 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-13 20:04 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On Mon, Dec 09, 2013 at 05:42:25PM +0800, Dave Young wrote:
> kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
> the kexec kernel efi runtime support also need read the old efi_info from
> boot_params. Currently it exists in debugfs which is not a good place for
> such infomation. Per HPA, we should avoid of "sploit debugfs".
>
> In this patch /sys/kernel/boot_params are exported, also the setup_data is
> exported as a subdirectory. kexec-tools is using debugfs for hardware_subarch
> for a long time now so we're not removing it yet.
>
> Structure is like below:
>
> /sys/kernel/boot_params
> |__ data /* boot_params in binary*/
> |__ setup_data
> | |__ 0 /* the first setup_data node */
> | | |__ data /* setup_data node 0 in binary*/
> | | |__ type /* setup_data type of setup_data node 0, hex string */
> [snip]
> |__ version /* boot protocal version (in hex, "0x" prefixed)*/
>
> Changelog:
> Greg: use __ATTR_RO() and group attr.
> Matt and Boris: Documentation improvement, code indentation.
>
> Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Acked-by: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH v5 13/14] x86: reserve setup_data ranges late after parsing memmap cmdline
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
Currently e820_reserve_setup_data is called before parsing early params,
it works in normal case. But for memmap=exactmap, the final memory ranges
are created after parsing memmap= cmdline params, so the previous
e820_reserve_setup_data has no effect. For example, setup_data ranges
will still be marked as normal system ram, thus when later sysfs driver
ioremap them kernel will warn about mapping normal ram.
This patch fix it by moving the e820_reserve_setup_data callback after
parsing early params so they can be set as reserved ranges and later
ioremap will be fine with it.
changes:
Boris: improve patch description
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/kernel/setup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index b2b54cd..a3357a6 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -927,8 +927,6 @@ void __init setup_arch(char **cmdline_p)
iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1;
setup_memory_map();
parse_setup_data();
- /* update the e820_saved too */
- e820_reserve_setup_data();
copy_edd();
@@ -990,6 +988,8 @@ void __init setup_arch(char **cmdline_p)
early_dump_pci_devices();
#endif
+ /* update the e820_saved too */
+ e820_reserve_setup_data();
finish_e820_parsing();
if (efi_enabled(EFI_BOOT))
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH v5 13/14] x86: reserve setup_data ranges late after parsing memmap cmdline
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
Currently e820_reserve_setup_data is called before parsing early params,
it works in normal case. But for memmap=exactmap, the final memory ranges
are created after parsing memmap= cmdline params, so the previous
e820_reserve_setup_data has no effect. For example, setup_data ranges
will still be marked as normal system ram, thus when later sysfs driver
ioremap them kernel will warn about mapping normal ram.
This patch fix it by moving the e820_reserve_setup_data callback after
parsing early params so they can be set as reserved ranges and later
ioremap will be fine with it.
changes:
Boris: improve patch description
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/kernel/setup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index b2b54cd..a3357a6 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -927,8 +927,6 @@ void __init setup_arch(char **cmdline_p)
iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1;
setup_memory_map();
parse_setup_data();
- /* update the e820_saved too */
- e820_reserve_setup_data();
copy_edd();
@@ -990,6 +988,8 @@ void __init setup_arch(char **cmdline_p)
early_dump_pci_devices();
#endif
+ /* update the e820_saved too */
+ e820_reserve_setup_data();
finish_e820_parsing();
if (efi_enabled(EFI_BOOT))
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH v5 13/14] x86: reserve setup_data ranges late after parsing memmap cmdline
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
Currently e820_reserve_setup_data is called before parsing early params,
it works in normal case. But for memmap=exactmap, the final memory ranges
are created after parsing memmap= cmdline params, so the previous
e820_reserve_setup_data has no effect. For example, setup_data ranges
will still be marked as normal system ram, thus when later sysfs driver
ioremap them kernel will warn about mapping normal ram.
This patch fix it by moving the e820_reserve_setup_data callback after
parsing early params so they can be set as reserved ranges and later
ioremap will be fine with it.
changes:
Boris: improve patch description
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
arch/x86/kernel/setup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index b2b54cd..a3357a6 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -927,8 +927,6 @@ void __init setup_arch(char **cmdline_p)
iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1;
setup_memory_map();
parse_setup_data();
- /* update the e820_saved too */
- e820_reserve_setup_data();
copy_edd();
@@ -990,6 +988,8 @@ void __init setup_arch(char **cmdline_p)
early_dump_pci_devices();
#endif
+ /* update the e820_saved too */
+ e820_reserve_setup_data();
finish_e820_parsing();
if (efi_enabled(EFI_BOOT))
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread
* Re: [PATCH v5 13/14] x86: reserve setup_data ranges late after parsing memmap cmdline
@ 2013-12-13 20:04 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-13 20:04 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On Mon, Dec 09, 2013 at 05:42:26PM +0800, Dave Young wrote:
> Currently e820_reserve_setup_data is called before parsing early params,
> it works in normal case. But for memmap=exactmap, the final memory ranges
> are created after parsing memmap= cmdline params, so the previous
> e820_reserve_setup_data has no effect. For example, setup_data ranges
> will still be marked as normal system ram, thus when later sysfs driver
> ioremap them kernel will warn about mapping normal ram.
>
> This patch fix it by moving the e820_reserve_setup_data callback after
> parsing early params so they can be set as reserved ranges and later
> ioremap will be fine with it.
>
> changes:
> Boris: improve patch description
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 13/14] x86: reserve setup_data ranges late after parsing memmap cmdline
@ 2013-12-13 20:04 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-13 20:04 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, vgoyal
On Mon, Dec 09, 2013 at 05:42:26PM +0800, Dave Young wrote:
> Currently e820_reserve_setup_data is called before parsing early params,
> it works in normal case. But for memmap=exactmap, the final memory ranges
> are created after parsing memmap= cmdline params, so the previous
> e820_reserve_setup_data has no effect. For example, setup_data ranges
> will still be marked as normal system ram, thus when later sysfs driver
> ioremap them kernel will warn about mapping normal ram.
>
> This patch fix it by moving the e820_reserve_setup_data callback after
> parsing early params so they can be set as reserved ranges and later
> ioremap will be fine with it.
>
> changes:
> Boris: improve patch description
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 13/14] x86: reserve setup_data ranges late after parsing memmap cmdline
@ 2013-12-13 20:04 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-13 20:04 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On Mon, Dec 09, 2013 at 05:42:26PM +0800, Dave Young wrote:
> Currently e820_reserve_setup_data is called before parsing early params,
> it works in normal case. But for memmap=exactmap, the final memory ranges
> are created after parsing memmap= cmdline params, so the previous
> e820_reserve_setup_data has no effect. For example, setup_data ranges
> will still be marked as normal system ram, thus when later sysfs driver
> ioremap them kernel will warn about mapping normal ram.
>
> This patch fix it by moving the e820_reserve_setup_data callback after
> parsing early params so they can be set as reserved ranges and later
> ioremap will be fine with it.
>
> changes:
> Boris: improve patch description
>
> Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Acked-by: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH v5 14/14] x86: kdebugfs do not use __va for getting setup_data virt addr
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, bp, greg, matt, toshi.kani
kdump kernel will use memmap=exactmap kernel cmdline, but __va does not
work in case memmap=exactmap, so let's always use ioremap_cache.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/kernel/kdebugfs.c | 35 +++++++++++------------------------
1 file changed, 11 insertions(+), 24 deletions(-)
diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
index dc1404b..185e1ca 100644
--- a/arch/x86/kernel/kdebugfs.c
+++ b/arch/x86/kernel/kdebugfs.c
@@ -33,7 +33,6 @@ static ssize_t setup_data_read(struct file *file, char __user *user_buf,
struct setup_data_node *node = file->private_data;
unsigned long remain;
loff_t pos = *ppos;
- struct page *pg;
void *p;
u64 pa;
@@ -47,18 +46,12 @@ static ssize_t setup_data_read(struct file *file, char __user *user_buf,
count = node->len - pos;
pa = node->paddr + sizeof(struct setup_data) + pos;
- pg = pfn_to_page((pa + count - 1) >> PAGE_SHIFT);
- if (PageHighMem(pg)) {
- p = ioremap_cache(pa, count);
- if (!p)
- return -ENXIO;
- } else
- p = __va(pa);
+ p = ioremap_cache(pa, count);
+ if (!p)
+ return -ENXIO;
remain = copy_to_user(user_buf, p, count);
-
- if (PageHighMem(pg))
- iounmap(p);
+ iounmap(p);
if (remain)
return -EFAULT;
@@ -109,7 +102,6 @@ static int __init create_setup_data_nodes(struct dentry *parent)
struct setup_data *data;
int error;
struct dentry *d;
- struct page *pg;
u64 pa_data;
int no = 0;
@@ -126,16 +118,12 @@ static int __init create_setup_data_nodes(struct dentry *parent)
goto err_dir;
}
- pg = pfn_to_page((pa_data+sizeof(*data)-1) >> PAGE_SHIFT);
- if (PageHighMem(pg)) {
- data = ioremap_cache(pa_data, sizeof(*data));
- if (!data) {
- kfree(node);
- error = -ENXIO;
- goto err_dir;
- }
- } else
- data = __va(pa_data);
+ data = ioremap_cache(pa_data, sizeof(*data));
+ if (!data) {
+ kfree(node);
+ error = -ENXIO;
+ goto err_dir;
+ }
node->paddr = pa_data;
node->type = data->type;
@@ -143,8 +131,7 @@ static int __init create_setup_data_nodes(struct dentry *parent)
error = create_setup_data_node(d, no, node);
pa_data = data->next;
- if (PageHighMem(pg))
- iounmap(data);
+ iounmap(data);
if (error)
goto err_dir;
no++;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 14/14] x86: kdebugfs do not use __va for getting setup_data virt addr
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
kdump kernel will use memmap=exactmap kernel cmdline, but __va does not
work in case memmap=exactmap, so let's always use ioremap_cache.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/kernel/kdebugfs.c | 35 +++++++++++------------------------
1 file changed, 11 insertions(+), 24 deletions(-)
diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
index dc1404b..185e1ca 100644
--- a/arch/x86/kernel/kdebugfs.c
+++ b/arch/x86/kernel/kdebugfs.c
@@ -33,7 +33,6 @@ static ssize_t setup_data_read(struct file *file, char __user *user_buf,
struct setup_data_node *node = file->private_data;
unsigned long remain;
loff_t pos = *ppos;
- struct page *pg;
void *p;
u64 pa;
@@ -47,18 +46,12 @@ static ssize_t setup_data_read(struct file *file, char __user *user_buf,
count = node->len - pos;
pa = node->paddr + sizeof(struct setup_data) + pos;
- pg = pfn_to_page((pa + count - 1) >> PAGE_SHIFT);
- if (PageHighMem(pg)) {
- p = ioremap_cache(pa, count);
- if (!p)
- return -ENXIO;
- } else
- p = __va(pa);
+ p = ioremap_cache(pa, count);
+ if (!p)
+ return -ENXIO;
remain = copy_to_user(user_buf, p, count);
-
- if (PageHighMem(pg))
- iounmap(p);
+ iounmap(p);
if (remain)
return -EFAULT;
@@ -109,7 +102,6 @@ static int __init create_setup_data_nodes(struct dentry *parent)
struct setup_data *data;
int error;
struct dentry *d;
- struct page *pg;
u64 pa_data;
int no = 0;
@@ -126,16 +118,12 @@ static int __init create_setup_data_nodes(struct dentry *parent)
goto err_dir;
}
- pg = pfn_to_page((pa_data+sizeof(*data)-1) >> PAGE_SHIFT);
- if (PageHighMem(pg)) {
- data = ioremap_cache(pa_data, sizeof(*data));
- if (!data) {
- kfree(node);
- error = -ENXIO;
- goto err_dir;
- }
- } else
- data = __va(pa_data);
+ data = ioremap_cache(pa_data, sizeof(*data));
+ if (!data) {
+ kfree(node);
+ error = -ENXIO;
+ goto err_dir;
+ }
node->paddr = pa_data;
node->type = data->type;
@@ -143,8 +131,7 @@ static int __init create_setup_data_nodes(struct dentry *parent)
error = create_setup_data_node(d, no, node);
pa_data = data->next;
- if (PageHighMem(pg))
- iounmap(data);
+ iounmap(data);
if (error)
goto err_dir;
no++;
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH v5 14/14] x86: kdebugfs do not use __va for getting setup_data virt addr
@ 2013-12-09 9:42 ` Dave Young
0 siblings, 0 replies; 183+ messages in thread
From: Dave Young @ 2013-12-09 9:42 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: mjg59-1xO5oi07KQx4cg9Nei1l7Q, linux-efi-u79uwXL29TY76Z2rM5mHXA,
toshi.kani-VXdhtT5mjnY, matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy,
greg-U8xfFu+wG4EAvxtiuMwx3w, x86-DgEjT+Ai2ygdnm+yROfE0A,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
horms-/R6kz+dDXgpPR4JQBCEnsQ, bp-Gina5bIWoIWzQB+pC5nmwQ,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, hpa-YMNOUZJC4hwAvxtiuMwx3w,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
kdump kernel will use memmap=exactmap kernel cmdline, but __va does not
work in case memmap=exactmap, so let's always use ioremap_cache.
Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
arch/x86/kernel/kdebugfs.c | 35 +++++++++++------------------------
1 file changed, 11 insertions(+), 24 deletions(-)
diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
index dc1404b..185e1ca 100644
--- a/arch/x86/kernel/kdebugfs.c
+++ b/arch/x86/kernel/kdebugfs.c
@@ -33,7 +33,6 @@ static ssize_t setup_data_read(struct file *file, char __user *user_buf,
struct setup_data_node *node = file->private_data;
unsigned long remain;
loff_t pos = *ppos;
- struct page *pg;
void *p;
u64 pa;
@@ -47,18 +46,12 @@ static ssize_t setup_data_read(struct file *file, char __user *user_buf,
count = node->len - pos;
pa = node->paddr + sizeof(struct setup_data) + pos;
- pg = pfn_to_page((pa + count - 1) >> PAGE_SHIFT);
- if (PageHighMem(pg)) {
- p = ioremap_cache(pa, count);
- if (!p)
- return -ENXIO;
- } else
- p = __va(pa);
+ p = ioremap_cache(pa, count);
+ if (!p)
+ return -ENXIO;
remain = copy_to_user(user_buf, p, count);
-
- if (PageHighMem(pg))
- iounmap(p);
+ iounmap(p);
if (remain)
return -EFAULT;
@@ -109,7 +102,6 @@ static int __init create_setup_data_nodes(struct dentry *parent)
struct setup_data *data;
int error;
struct dentry *d;
- struct page *pg;
u64 pa_data;
int no = 0;
@@ -126,16 +118,12 @@ static int __init create_setup_data_nodes(struct dentry *parent)
goto err_dir;
}
- pg = pfn_to_page((pa_data+sizeof(*data)-1) >> PAGE_SHIFT);
- if (PageHighMem(pg)) {
- data = ioremap_cache(pa_data, sizeof(*data));
- if (!data) {
- kfree(node);
- error = -ENXIO;
- goto err_dir;
- }
- } else
- data = __va(pa_data);
+ data = ioremap_cache(pa_data, sizeof(*data));
+ if (!data) {
+ kfree(node);
+ error = -ENXIO;
+ goto err_dir;
+ }
node->paddr = pa_data;
node->type = data->type;
@@ -143,8 +131,7 @@ static int __init create_setup_data_nodes(struct dentry *parent)
error = create_setup_data_node(d, no, node);
pa_data = data->next;
- if (PageHighMem(pg))
- iounmap(data);
+ iounmap(data);
if (error)
goto err_dir;
no++;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 183+ messages in thread
* Re: [PATCH v5 00/14] kexec kernel efi runtime support
@ 2013-12-10 23:25 ` Andrew Morton
0 siblings, 0 replies; 183+ messages in thread
From: Andrew Morton @ 2013-12-10 23:25 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, bp, greg, matt, toshi.kani
On Mon, 9 Dec 2013 17:42:13 +0800 Dave Young <dyoung@redhat.com> wrote:
> Here is the V5 patchset for supporting kexec kernel efi runtime.
It's unclear (to me) who's supposed to merge this lot. It's a "kexec"
patch which actually hits on efi and x86.
I grabbed them for some -next testing but won't be offended if someone
else merges them ;)
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 00/14] kexec kernel efi runtime support
@ 2013-12-10 23:25 ` Andrew Morton
0 siblings, 0 replies; 183+ messages in thread
From: Andrew Morton @ 2013-12-10 23:25 UTC (permalink / raw)
To: Dave Young
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, bp, ebiederm, hpa, vgoyal
On Mon, 9 Dec 2013 17:42:13 +0800 Dave Young <dyoung@redhat.com> wrote:
> Here is the V5 patchset for supporting kexec kernel efi runtime.
It's unclear (to me) who's supposed to merge this lot. It's a "kexec"
patch which actually hits on efi and x86.
I grabbed them for some -next testing but won't be offended if someone
else merges them ;)
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 00/14] kexec kernel efi runtime support
@ 2013-12-10 23:25 ` Andrew Morton
0 siblings, 0 replies; 183+ messages in thread
From: Andrew Morton @ 2013-12-10 23:25 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q, hpa-YMNOUZJC4hwAvxtiuMwx3w,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bp-Gina5bIWoIWzQB+pC5nmwQ, greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On Mon, 9 Dec 2013 17:42:13 +0800 Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> Here is the V5 patchset for supporting kexec kernel efi runtime.
It's unclear (to me) who's supposed to merge this lot. It's a "kexec"
patch which actually hits on efi and x86.
I grabbed them for some -next testing but won't be offended if someone
else merges them ;)
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 00/14] kexec kernel efi runtime support
2013-12-10 23:25 ` Andrew Morton
@ 2013-12-10 23:32 ` Borislav Petkov
-1 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-10 23:32 UTC (permalink / raw)
To: Andrew Morton
Cc: Dave Young, linux-kernel, linux-efi, x86, mjg59, hpa,
James.Bottomley, vgoyal, ebiederm, horms, kexec, greg, matt,
toshi.kani
On Tue, Dec 10, 2013 at 03:25:49PM -0800, Andrew Morton wrote:
> On Mon, 9 Dec 2013 17:42:13 +0800 Dave Young <dyoung@redhat.com> wrote:
>
> > Here is the V5 patchset for supporting kexec kernel efi runtime.
>
> It's unclear (to me) who's supposed to merge this lot. It's a "kexec"
> patch which actually hits on efi and x86.
>
> I grabbed them for some -next testing but won't be offended if someone
> else merges them ;)
I was under the impression that this should go through Matt's efi tree.
Oh, and we need to finish reviewing them so picking them up now would be
too premature, IMHO.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 00/14] kexec kernel efi runtime support
@ 2013-12-10 23:32 ` Borislav Petkov
0 siblings, 0 replies; 183+ messages in thread
From: Borislav Petkov @ 2013-12-10 23:32 UTC (permalink / raw)
To: Andrew Morton
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, hpa, Dave Young,
vgoyal
On Tue, Dec 10, 2013 at 03:25:49PM -0800, Andrew Morton wrote:
> On Mon, 9 Dec 2013 17:42:13 +0800 Dave Young <dyoung@redhat.com> wrote:
>
> > Here is the V5 patchset for supporting kexec kernel efi runtime.
>
> It's unclear (to me) who's supposed to merge this lot. It's a "kexec"
> patch which actually hits on efi and x86.
>
> I grabbed them for some -next testing but won't be offended if someone
> else merges them ;)
I was under the impression that this should go through Matt's efi tree.
Oh, and we need to finish reviewing them so picking them up now would be
too premature, IMHO.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH v5 00/14] kexec kernel efi runtime support
@ 2013-12-10 23:38 ` H. Peter Anvin
0 siblings, 0 replies; 183+ messages in thread
From: H. Peter Anvin @ 2013-12-10 23:38 UTC (permalink / raw)
To: Borislav Petkov, Andrew Morton
Cc: Dave Young, linux-kernel, linux-efi, x86, mjg59, James.Bottomley,
vgoyal, ebiederm, horms, kexec, greg, matt, toshi.kani
On 12/10/2013 03:32 PM, Borislav Petkov wrote:
> On Tue, Dec 10, 2013 at 03:25:49PM -0800, Andrew Morton wrote:
>> On Mon, 9 Dec 2013 17:42:13 +0800 Dave Young <dyoung@redhat.com> wrote:
>>
>>> Here is the V5 patchset for supporting kexec kernel efi runtime.
>>
>> It's unclear (to me) who's supposed to merge this lot. It's a "kexec"
>> patch which actually hits on efi and x86.
>>
>> I grabbed them for some -next testing but won't be offended if someone
>> else merges them ;)
>
> I was under the impression that this should go through Matt's efi tree.
> Oh, and we need to finish reviewing them so picking them up now would be
> too premature, IMHO.
>
My intent was to pick them into a separate branch of the tip tree either
directly or via Matt (since Matt feeds us anyway.)
But yes, work is still underway, although it is getting there.
-hpa
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 00/14] kexec kernel efi runtime support
@ 2013-12-10 23:38 ` H. Peter Anvin
0 siblings, 0 replies; 183+ messages in thread
From: H. Peter Anvin @ 2013-12-10 23:38 UTC (permalink / raw)
To: Borislav Petkov, Andrew Morton
Cc: mjg59, linux-efi, toshi.kani, matt, greg, x86, kexec,
linux-kernel, James.Bottomley, horms, ebiederm, Dave Young,
vgoyal
On 12/10/2013 03:32 PM, Borislav Petkov wrote:
> On Tue, Dec 10, 2013 at 03:25:49PM -0800, Andrew Morton wrote:
>> On Mon, 9 Dec 2013 17:42:13 +0800 Dave Young <dyoung@redhat.com> wrote:
>>
>>> Here is the V5 patchset for supporting kexec kernel efi runtime.
>>
>> It's unclear (to me) who's supposed to merge this lot. It's a "kexec"
>> patch which actually hits on efi and x86.
>>
>> I grabbed them for some -next testing but won't be offended if someone
>> else merges them ;)
>
> I was under the impression that this should go through Matt's efi tree.
> Oh, and we need to finish reviewing them so picking them up now would be
> too premature, IMHO.
>
My intent was to pick them into a separate branch of the tip tree either
directly or via Matt (since Matt feeds us anyway.)
But yes, work is still underway, although it is getting there.
-hpa
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 00/14] kexec kernel efi runtime support
@ 2013-12-10 23:38 ` H. Peter Anvin
0 siblings, 0 replies; 183+ messages in thread
From: H. Peter Anvin @ 2013-12-10 23:38 UTC (permalink / raw)
To: Borislav Petkov, Andrew Morton
Cc: Dave Young, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w,
matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy, toshi.kani-VXdhtT5mjnY
On 12/10/2013 03:32 PM, Borislav Petkov wrote:
> On Tue, Dec 10, 2013 at 03:25:49PM -0800, Andrew Morton wrote:
>> On Mon, 9 Dec 2013 17:42:13 +0800 Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>>> Here is the V5 patchset for supporting kexec kernel efi runtime.
>>
>> It's unclear (to me) who's supposed to merge this lot. It's a "kexec"
>> patch which actually hits on efi and x86.
>>
>> I grabbed them for some -next testing but won't be offended if someone
>> else merges them ;)
>
> I was under the impression that this should go through Matt's efi tree.
> Oh, and we need to finish reviewing them so picking them up now would be
> too premature, IMHO.
>
My intent was to pick them into a separate branch of the tip tree either
directly or via Matt (since Matt feeds us anyway.)
But yes, work is still underway, although it is getting there.
-hpa
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 00/14] kexec kernel efi runtime support
@ 2013-12-11 12:37 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 12:37 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Borislav Petkov, Andrew Morton, Dave Young, linux-kernel,
linux-efi, x86, mjg59, James.Bottomley, vgoyal, ebiederm, horms,
kexec, greg, toshi.kani
On Tue, 10 Dec, at 03:38:01PM, H. Peter Anvin wrote:
> My intent was to pick them into a separate branch of the tip tree either
> directly or via Matt (since Matt feeds us anyway.)
>
> But yes, work is still underway, although it is getting there.
Yeah, I've only found a few minor nits this time. I'll merge this soon -
presumably after the next revision.
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 00/14] kexec kernel efi runtime support
@ 2013-12-11 12:37 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 12:37 UTC (permalink / raw)
To: H. Peter Anvin
Cc: mjg59, linux-efi, toshi.kani, greg, x86, kexec, linux-kernel,
James.Bottomley, horms, Borislav Petkov, ebiederm, Andrew Morton,
Dave Young, vgoyal
On Tue, 10 Dec, at 03:38:01PM, H. Peter Anvin wrote:
> My intent was to pick them into a separate branch of the tip tree either
> directly or via Matt (since Matt feeds us anyway.)
>
> But yes, work is still underway, although it is getting there.
Yeah, I've only found a few minor nits this time. I'll merge this soon -
presumably after the next revision.
--
Matt Fleming, Intel Open Source Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH v5 00/14] kexec kernel efi runtime support
@ 2013-12-11 12:37 ` Matt Fleming
0 siblings, 0 replies; 183+ messages in thread
From: Matt Fleming @ 2013-12-11 12:37 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Borislav Petkov, Andrew Morton, Dave Young,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-efi-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
mjg59-1xO5oi07KQx4cg9Nei1l7Q,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
horms-/R6kz+dDXgpPR4JQBCEnsQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
greg-U8xfFu+wG4EAvxtiuMwx3w, toshi.kani-VXdhtT5mjnY
On Tue, 10 Dec, at 03:38:01PM, H. Peter Anvin wrote:
> My intent was to pick them into a separate branch of the tip tree either
> directly or via Matt (since Matt feeds us anyway.)
>
> But yes, work is still underway, although it is getting there.
Yeah, I've only found a few minor nits this time. I'll merge this soon -
presumably after the next revision.
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 183+ messages in thread