* [patch 1/6] Add function efi_remap_region for remapping to saved virt address
2013-10-27 3:47 [patch 0/6] kexec kernel efi runtime support dyoung
@ 2013-10-27 3:47 ` dyoung
2013-10-27 11:50 ` Borislav Petkov
2013-10-27 3:47 ` [patch 3/6] Cleanup efi_enter_virtual_mode function dyoung
` (4 subsequent siblings)
5 siblings, 1 reply; 36+ messages in thread
From: dyoung @ 2013-10-27 3:47 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, kexec, bp, Dave Young
[-- Attachment #1: 04-efi-map-fixed-addr.patch --]
[-- Type: text/plain, Size: 1943 bytes --]
Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_remap_region to remapping it directly without
calculate the virt addr from efi_va.
The md is passed in from 1st kernel, the virtual addr is
saved in md->virt_addr.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/include/asm/efi.h | 1 +
arch/x86/platform/efi/efi_32.c | 4 ++++
arch/x86/platform/efi/efi_64.c | 13 +++++++++++++
3 files changed, 18 insertions(+)
--- linux-2.6.orig/arch/x86/include/asm/efi.h
+++ linux-2.6/arch/x86/include/asm/efi.h
@@ -112,6 +112,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_remap_region(efi_memory_desc_t *md);
extern void efi_sync_low_kernel_mappings(void);
extern void __init old_map_region(efi_memory_desc_t *md);
--- linux-2.6.orig/arch/x86/platform/efi/efi_64.c
+++ linux-2.6/arch/x86/platform/efi/efi_64.c
@@ -177,6 +177,19 @@ void __init efi_map_region(efi_memory_de
md->virt_addr = efi_va;
}
+void __init efi_remap_region(efi_memory_desc_t *md)
+{
+ pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
+ unsigned long pf = 0;
+
+ if (!(md->attribute & EFI_MEMORY_WB))
+ pf |= _PAGE_PCD;
+
+ if(kernel_map_pages_in_pgd(pgd, md->phys_addr, md->virt_addr, md->num_pages, pf))
+ pr_warning("Error mapping PA 0x%llx -> VA 0x%llx!\n",
+ md->phys_addr, md->virt_addr);
+}
+
void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
u32 type, u64 attribute)
{
--- linux-2.6.orig/arch/x86/platform/efi/efi_32.c
+++ linux-2.6/arch/x86/platform/efi/efi_32.c
@@ -46,6 +46,10 @@ void __init efi_map_region(efi_memory_de
old_map_region(md);
}
+void __init efi_remap_region(efi_memory_desc_t *md)
+{
+}
+
void efi_call_phys_prelog(void)
{
struct desc_ptr gdt_descr;
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 1/6] Add function efi_remap_region for remapping to saved virt address
2013-10-27 3:47 ` [patch 1/6] Add function efi_remap_region for remapping to saved virt address dyoung
@ 2013-10-27 11:50 ` Borislav Petkov
2013-10-28 1:25 ` Dave Young
0 siblings, 1 reply; 36+ messages in thread
From: Borislav Petkov @ 2013-10-27 11:50 UTC (permalink / raw)
To: dyoung
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On Sun, Oct 27, 2013 at 11:47:14AM +0800, dyoung@redhat.com wrote:
> Kexec kernel will use saved runtime virtual mapping, so add a
> new function efi_remap_region to remapping it directly without
> calculate the virt addr from efi_va.
>
> The md is passed in from 1st kernel, the virtual addr is
> saved in md->virt_addr.
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/include/asm/efi.h | 1 +
> arch/x86/platform/efi/efi_32.c | 4 ++++
> arch/x86/platform/efi/efi_64.c | 13 +++++++++++++
> 3 files changed, 18 insertions(+)
>
> --- linux-2.6.orig/arch/x86/include/asm/efi.h
> +++ linux-2.6/arch/x86/include/asm/efi.h
> @@ -112,6 +112,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_remap_region(efi_memory_desc_t *md);
> extern void efi_sync_low_kernel_mappings(void);
> extern void __init old_map_region(efi_memory_desc_t *md);
>
> --- linux-2.6.orig/arch/x86/platform/efi/efi_64.c
> +++ linux-2.6/arch/x86/platform/efi/efi_64.c
> @@ -177,6 +177,19 @@ void __init efi_map_region(efi_memory_de
> md->virt_addr = efi_va;
> }
>
> +void __init efi_remap_region(efi_memory_desc_t *md)
remap? Why?
You did have efi_map_region_fixed() which made more sense.
> +{
> + pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
> + unsigned long pf = 0;
> +
> + if (!(md->attribute & EFI_MEMORY_WB))
> + pf |= _PAGE_PCD;
> +
> + if(kernel_map_pages_in_pgd(pgd, md->phys_addr, md->virt_addr, md->num_pages, pf))
ERROR: space required before the open parenthesis '('
#59: FILE: arch/x86/platform/efi/efi_64.c:188:
+ if(kernel_map_pages_in_pgd(pgd, md->phys_addr, md->virt_addr, md->num_pages, pf))
Please run them all through checkpatch.pl - better yet, integrate
checkpatch into your workflow like using git hooks, for example.
> + pr_warning("Error mapping PA 0x%llx -> VA 0x%llx!\n",
WARNING: Prefer pr_warn(... to pr_warning(...
#60: FILE: arch/x86/platform/efi/efi_64.c:189:
+ pr_warning("Error mapping PA 0x%llx -> VA 0x%llx!\n",
> + md->phys_addr, md->virt_addr);
> +}
> +
> void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
> u32 type, u64 attribute)
> {
> --- linux-2.6.orig/arch/x86/platform/efi/efi_32.c
> +++ linux-2.6/arch/x86/platform/efi/efi_32.c
> @@ -46,6 +46,10 @@ void __init efi_map_region(efi_memory_de
> old_map_region(md);
> }
>
> +void __init efi_remap_region(efi_memory_desc_t *md)
> +{
> +}
Let's keep braces on the same line as the function to save space:
void __init efi_remap_region(efi_memory_desc_t *md) {}
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 1/6] Add function efi_remap_region for remapping to saved virt address
2013-10-27 11:50 ` Borislav Petkov
@ 2013-10-28 1:25 ` Dave Young
0 siblings, 0 replies; 36+ messages in thread
From: Dave Young @ 2013-10-28 1:25 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
Hi, Thanks for review
On 10/27/13 at 12:50pm, Borislav Petkov wrote:
> On Sun, Oct 27, 2013 at 11:47:14AM +0800, dyoung@redhat.com wrote:
> > Kexec kernel will use saved runtime virtual mapping, so add a
> > new function efi_remap_region to remapping it directly without
> > calculate the virt addr from efi_va.
> >
> > The md is passed in from 1st kernel, the virtual addr is
> > saved in md->virt_addr.
> >
> > Signed-off-by: Dave Young <dyoung@redhat.com>
> > ---
> > arch/x86/include/asm/efi.h | 1 +
> > arch/x86/platform/efi/efi_32.c | 4 ++++
> > arch/x86/platform/efi/efi_64.c | 13 +++++++++++++
> > 3 files changed, 18 insertions(+)
> >
> > --- linux-2.6.orig/arch/x86/include/asm/efi.h
> > +++ linux-2.6/arch/x86/include/asm/efi.h
> > @@ -112,6 +112,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_remap_region(efi_memory_desc_t *md);
> > extern void efi_sync_low_kernel_mappings(void);
> > extern void __init old_map_region(efi_memory_desc_t *md);
> >
> > --- linux-2.6.orig/arch/x86/platform/efi/efi_64.c
> > +++ linux-2.6/arch/x86/platform/efi/efi_64.c
> > @@ -177,6 +177,19 @@ void __init efi_map_region(efi_memory_de
> > md->virt_addr = efi_va;
> > }
> >
> > +void __init efi_remap_region(efi_memory_desc_t *md)
>
> remap? Why?
>
> You did have efi_map_region_fixed() which made more sense.
remap here means mapping to same virt addr in 2nd kernel, I feel
it's a little better, but I have no strong opinion.
Will change to _fixed
>
> > +{
> > + pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
> > + unsigned long pf = 0;
> > +
> > + if (!(md->attribute & EFI_MEMORY_WB))
> > + pf |= _PAGE_PCD;
> > +
> > + if(kernel_map_pages_in_pgd(pgd, md->phys_addr, md->virt_addr, md->num_pages, pf))
>
> ERROR: space required before the open parenthesis '('
> #59: FILE: arch/x86/platform/efi/efi_64.c:188:
> + if(kernel_map_pages_in_pgd(pgd, md->phys_addr, md->virt_addr, md->num_pages, pf))
Will fix
>
>
> Please run them all through checkpatch.pl - better yet, integrate
> checkpatch into your workflow like using git hooks, for example.
Hmm, will do. Have been long time being away from sending patches.
>
> > + pr_warning("Error mapping PA 0x%llx -> VA 0x%llx!\n",
>
> WARNING: Prefer pr_warn(... to pr_warning(...
> #60: FILE: arch/x86/platform/efi/efi_64.c:189:
> + pr_warning("Error mapping PA 0x%llx -> VA 0x%llx!\n",
Will fix
>
> > + md->phys_addr, md->virt_addr);
> > +}
> > +
> > void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
> > u32 type, u64 attribute)
> > {
> > --- linux-2.6.orig/arch/x86/platform/efi/efi_32.c
> > +++ linux-2.6/arch/x86/platform/efi/efi_32.c
> > @@ -46,6 +46,10 @@ void __init efi_map_region(efi_memory_de
> > old_map_region(md);
> > }
> >
> > +void __init efi_remap_region(efi_memory_desc_t *md)
> > +{
> > +}
>
> Let's keep braces on the same line as the function to save space:
Ok, will update
>
> void __init efi_remap_region(efi_memory_desc_t *md) {}
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
^ permalink raw reply [flat|nested] 36+ messages in thread
* [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-27 3:47 [patch 0/6] kexec kernel efi runtime support dyoung
2013-10-27 3:47 ` [patch 1/6] Add function efi_remap_region for remapping to saved virt address dyoung
@ 2013-10-27 3:47 ` dyoung
2013-10-28 9:32 ` Borislav Petkov
2013-10-27 3:47 ` [patch 4/6] export more efi table variable to sysfs dyoung
` (3 subsequent siblings)
5 siblings, 1 reply; 36+ messages in thread
From: dyoung @ 2013-10-27 3:47 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, kexec, bp, Dave Young
[-- Attachment #1: 02-efi-enter-virtual-mode-cleanup-1.patch --]
[-- Type: text/plain, Size: 3598 bytes --]
Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/platform/efi/efi.c | 83 +++++++++++++++++++++++++++-----------------
1 file changed, 52 insertions(+), 31 deletions(-)
--- efi.orig/arch/x86/platform/efi/efi.c
+++ efi/arch/x86/platform/efi/efi.c
@@ -789,35 +789,13 @@ void __init old_map_region(efi_memory_de
pr_err("ioremap of 0x%llX failed!\n",
(unsigned long long)md->phys_addr);
}
-/*
- * This function will switch the EFI runtime services to virtual mode.
- * Essentially, look through the EFI memmap and map every region that
- * has the runtime attribute bit set in its memory descriptor and update
- * that memory descriptor with the virtual address obtained from ioremap().
- * This enables the runtime services to be called without having to
- * thunk back into physical mode for every invocation.
- */
-void __init efi_enter_virtual_mode(void)
-{
- 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 */
+static void efi_merge_regions(void)
+{
+ void *p;
+ efi_memory_desc_t *md, *prev_md = NULL;
- /* 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;
@@ -844,6 +822,19 @@ void __init efi_enter_virtual_mode(void)
prev_md = md;
}
+}
+
+/*
+ * Map efi memory ranges for runtime serivce
+ * Return the new memmap with updated virtual addrresses.
+ */
+void efi_map_regions(void **new_memmap, int *count)
+{
+ efi_memory_desc_t *md, *prev_md = NULL;
+ void *p;
+ unsigned long size;
+ efi_status_t status;
+ u64 end, systab;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
@@ -862,14 +853,44 @@ void __init efi_enter_virtual_mode(void)
systab += md->virt_addr - md->phys_addr;
efi.systab = (efi_system_table_t *) (unsigned long) systab;
}
- new_memmap = krealloc(new_memmap,
- (count + 1) * memmap.desc_size,
+ *new_memmap = krealloc(*new_memmap,
+ (*count + 1) * memmap.desc_size,
GFP_KERNEL);
- memcpy(new_memmap + (count * memmap.desc_size), md,
+ memcpy(*new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
- count++;
+ (*count)++;
+ }
+}
+
+/*
+ * This function will switch the EFI runtime services to virtual mode.
+ * Essentially, look through the EFI memmap and map every region that
+ * has the runtime attribute bit set in its memory descriptor and update
+ * that memory descriptor with the virtual address obtained from ioremap().
+ * This enables the runtime services to be called without having to
+ * thunk back into physical mode for every invocation.
+ */
+void __init efi_enter_virtual_mode(void)
+{
+ efi_status_t status;
+ void *p, *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();
+
+ efi_map_regions(&new_memmap, &count);
+
#ifdef CONFIG_X86_64
efi_scratch.efi_pgt = (pgd_t *)(unsigned long)real_mode_header->trampoline_pgd;
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-27 3:47 ` [patch 3/6] Cleanup efi_enter_virtual_mode function dyoung
@ 2013-10-28 9:32 ` Borislav Petkov
2013-10-28 9:40 ` Dave Young
0 siblings, 1 reply; 36+ messages in thread
From: Borislav Petkov @ 2013-10-28 9:32 UTC (permalink / raw)
To: dyoung
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On Sun, Oct 27, 2013 at 11:47:16AM +0800, dyoung@redhat.com wrote:
> Add two small functions:
> efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
> calls them instead of embedding two long for loop.
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/platform/efi/efi.c | 83 +++++++++++++++++++++++++++-----------------
> 1 file changed, 52 insertions(+), 31 deletions(-)
>
> --- efi.orig/arch/x86/platform/efi/efi.c
> +++ efi/arch/x86/platform/efi/efi.c
> @@ -789,35 +789,13 @@ void __init old_map_region(efi_memory_de
> pr_err("ioremap of 0x%llX failed!\n",
> (unsigned long long)md->phys_addr);
> }
> -/*
> - * This function will switch the EFI runtime services to virtual mode.
> - * Essentially, look through the EFI memmap and map every region that
> - * has the runtime attribute bit set in its memory descriptor and update
> - * that memory descriptor with the virtual address obtained from ioremap().
> - * This enables the runtime services to be called without having to
> - * thunk back into physical mode for every invocation.
> - */
> -void __init efi_enter_virtual_mode(void)
> -{
> - 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 */
> +static void efi_merge_regions(void)
> +{
> + void *p;
> + efi_memory_desc_t *md, *prev_md = NULL;
>
> - /* 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;
> @@ -844,6 +822,19 @@ void __init efi_enter_virtual_mode(void)
> prev_md = md;
>
> }
> +}
> +
> +/*
> + * Map efi memory ranges for runtime serivce
> + * Return the new memmap with updated virtual addrresses.
> + */
> +void efi_map_regions(void **new_memmap, int *count)
> +{
> + efi_memory_desc_t *md, *prev_md = NULL;
Applying: Cleanup efi_enter_virtual_mode function
/home/boris/kernel/linux-2.6/.git/rebase-apply/patch:42: space before tab in indent.
efi_memory_desc_t *md, *prev_md = NULL;
error: patch failed: arch/x86/platform/efi/efi.c:862
error: arch/x86/platform/efi/efi.c: patch does not apply
Patch failed at 0001 Cleanup efi_enter_virtual_mode function
And I know git can be a bit pickier than patch but it doesn't apply with patch
either:
$ patch -p1 --dry-run -i .git/rebase-apply/patch
checking file arch/x86/platform/efi/efi.c
Hunk #3 FAILED at 853.
1 out of 3 hunks FAILED
For some reason, this patch doesn't apply and the .rej looks funny.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-28 9:32 ` Borislav Petkov
@ 2013-10-28 9:40 ` Dave Young
2013-10-28 9:51 ` Dave Young
0 siblings, 1 reply; 36+ messages in thread
From: Dave Young @ 2013-10-28 9:40 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On 10/28/13 at 10:32am, Borislav Petkov wrote:
> On Sun, Oct 27, 2013 at 11:47:16AM +0800, dyoung@redhat.com wrote:
> > Add two small functions:
> > efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
> > calls them instead of embedding two long for loop.
> >
> > Signed-off-by: Dave Young <dyoung@redhat.com>
> > ---
> > arch/x86/platform/efi/efi.c | 83 +++++++++++++++++++++++++++-----------------
> > 1 file changed, 52 insertions(+), 31 deletions(-)
> >
> > --- efi.orig/arch/x86/platform/efi/efi.c
> > +++ efi/arch/x86/platform/efi/efi.c
> > @@ -789,35 +789,13 @@ void __init old_map_region(efi_memory_de
> > pr_err("ioremap of 0x%llX failed!\n",
> > (unsigned long long)md->phys_addr);
> > }
> > -/*
> > - * This function will switch the EFI runtime services to virtual mode.
> > - * Essentially, look through the EFI memmap and map every region that
> > - * has the runtime attribute bit set in its memory descriptor and update
> > - * that memory descriptor with the virtual address obtained from ioremap().
> > - * This enables the runtime services to be called without having to
> > - * thunk back into physical mode for every invocation.
> > - */
> > -void __init efi_enter_virtual_mode(void)
> > -{
> > - 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 */
> > +static void efi_merge_regions(void)
> > +{
> > + void *p;
> > + efi_memory_desc_t *md, *prev_md = NULL;
> >
> > - /* 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;
> > @@ -844,6 +822,19 @@ void __init efi_enter_virtual_mode(void)
> > prev_md = md;
> >
> > }
> > +}
> > +
> > +/*
> > + * Map efi memory ranges for runtime serivce
> > + * Return the new memmap with updated virtual addrresses.
> > + */
> > +void efi_map_regions(void **new_memmap, int *count)
> > +{
> > + efi_memory_desc_t *md, *prev_md = NULL;
>
> Applying: Cleanup efi_enter_virtual_mode function
> /home/boris/kernel/linux-2.6/.git/rebase-apply/patch:42: space before tab in indent.
> efi_memory_desc_t *md, *prev_md = NULL;
> error: patch failed: arch/x86/platform/efi/efi.c:862
> error: arch/x86/platform/efi/efi.c: patch does not apply
> Patch failed at 0001 Cleanup efi_enter_virtual_mode function
>
> And I know git can be a bit pickier than patch but it doesn't apply with patch
> either:
>
> $ patch -p1 --dry-run -i .git/rebase-apply/patch
> checking file arch/x86/platform/efi/efi.c
> Hunk #3 FAILED at 853.
> 1 out of 3 hunks FAILED
>
> For some reason, this patch doesn't apply and the .rej looks funny.
It's stange, but I did use git to generate patch, I use quilt instead.
Will have a try with git.
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-28 9:40 ` Dave Young
@ 2013-10-28 9:51 ` Dave Young
2013-10-28 10:04 ` Borislav Petkov
0 siblings, 1 reply; 36+ messages in thread
From: Dave Young @ 2013-10-28 9:51 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On 10/28/13 at 05:40pm, Dave Young wrote:
> On 10/28/13 at 10:32am, Borislav Petkov wrote:
> > On Sun, Oct 27, 2013 at 11:47:16AM +0800, dyoung@redhat.com wrote:
> > > Add two small functions:
> > > efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
> > > calls them instead of embedding two long for loop.
> > >
> > > Signed-off-by: Dave Young <dyoung@redhat.com>
> > > ---
> > > arch/x86/platform/efi/efi.c | 83 +++++++++++++++++++++++++++-----------------
> > > 1 file changed, 52 insertions(+), 31 deletions(-)
> > >
> > > --- efi.orig/arch/x86/platform/efi/efi.c
> > > +++ efi/arch/x86/platform/efi/efi.c
> > > @@ -789,35 +789,13 @@ void __init old_map_region(efi_memory_de
> > > pr_err("ioremap of 0x%llX failed!\n",
> > > (unsigned long long)md->phys_addr);
> > > }
> > > -/*
> > > - * This function will switch the EFI runtime services to virtual mode.
> > > - * Essentially, look through the EFI memmap and map every region that
> > > - * has the runtime attribute bit set in its memory descriptor and update
> > > - * that memory descriptor with the virtual address obtained from ioremap().
> > > - * This enables the runtime services to be called without having to
> > > - * thunk back into physical mode for every invocation.
> > > - */
> > > -void __init efi_enter_virtual_mode(void)
> > > -{
> > > - 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 */
> > > +static void efi_merge_regions(void)
> > > +{
> > > + void *p;
> > > + efi_memory_desc_t *md, *prev_md = NULL;
> > >
> > > - /* 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;
> > > @@ -844,6 +822,19 @@ void __init efi_enter_virtual_mode(void)
> > > prev_md = md;
> > >
> > > }
> > > +}
> > > +
> > > +/*
> > > + * Map efi memory ranges for runtime serivce
> > > + * Return the new memmap with updated virtual addrresses.
> > > + */
> > > +void efi_map_regions(void **new_memmap, int *count)
> > > +{
> > > + efi_memory_desc_t *md, *prev_md = NULL;
> >
> > Applying: Cleanup efi_enter_virtual_mode function
> > /home/boris/kernel/linux-2.6/.git/rebase-apply/patch:42: space before tab in indent.
> > efi_memory_desc_t *md, *prev_md = NULL;
> > error: patch failed: arch/x86/platform/efi/efi.c:862
> > error: arch/x86/platform/efi/efi.c: patch does not apply
> > Patch failed at 0001 Cleanup efi_enter_virtual_mode function
> >
> > And I know git can be a bit pickier than patch but it doesn't apply with patch
> > either:
> >
> > $ patch -p1 --dry-run -i .git/rebase-apply/patch
> > checking file arch/x86/platform/efi/efi.c
> > Hunk #3 FAILED at 853.
> > 1 out of 3 hunks FAILED
> >
> > For some reason, this patch doesn't apply and the .rej looks funny.
>
> It's stange, but I did use git to generate patch, I use quilt instead.
> Will have a try with git.
It does have a warning, but it applied successfully, no idea though:
patches/02-efi-enter-virtual-mode-cleanup.patch
Applying: Cleanup efi_enter_virtual_mode function
/home/dave/git/efi/.git/rebase-apply/patch:42: space before tab in indent.
efi_memory_desc_t *md, *prev_md = NULL;
warning: 1 line adds whitespace errors.
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-28 9:51 ` Dave Young
@ 2013-10-28 10:04 ` Borislav Petkov
2013-10-28 10:10 ` Dave Young
0 siblings, 1 reply; 36+ messages in thread
From: Borislav Petkov @ 2013-10-28 10:04 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On Mon, Oct 28, 2013 at 05:51:17PM +0800, Dave Young wrote:
> It does have a warning, but it applied successfully, no idea though:
> patches/02-efi-enter-virtual-mode-cleanup.patch
> Applying: Cleanup efi_enter_virtual_mode function
> /home/dave/git/efi/.git/rebase-apply/patch:42: space before tab in indent.
> efi_memory_desc_t *md, *prev_md = NULL;
> warning: 1 line adds whitespace errors.
Hmm, ok, can you upload the patches somewhere so that I can pull them?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-28 10:04 ` Borislav Petkov
@ 2013-10-28 10:10 ` Dave Young
2013-10-28 10:39 ` Dave Young
2013-10-28 11:20 ` Borislav Petkov
0 siblings, 2 replies; 36+ messages in thread
From: Dave Young @ 2013-10-28 10:10 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
[-- Attachment #1: Type: text/plain, Size: 735 bytes --]
On 10/28/13 at 11:04am, Borislav Petkov wrote:
> On Mon, Oct 28, 2013 at 05:51:17PM +0800, Dave Young wrote:
> > It does have a warning, but it applied successfully, no idea though:
> > patches/02-efi-enter-virtual-mode-cleanup.patch
> > Applying: Cleanup efi_enter_virtual_mode function
> > /home/dave/git/efi/.git/rebase-apply/patch:42: space before tab in indent.
> > efi_memory_desc_t *md, *prev_md = NULL;
> > warning: 1 line adds whitespace errors.
>
> Hmm, ok, can you upload the patches somewhere so that I can pull them?
Sorry, I have not any public git account. Attached the patch I applied with git
>
> Thanks.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
[-- Attachment #2: 02-efi-enter-virtual-mode-cleanup-1.patch.new --]
[-- Type: text/plain, Size: 3675 bytes --]
From: Dave Young <dyoung@redhat.com>
Cleanup efi_enter_virtual_mode function
Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/platform/efi/efi.c | 83 +++++++++++++++++++++++++++-----------------
1 file changed, 52 insertions(+), 31 deletions(-)
--- efi.orig/arch/x86/platform/efi/efi.c
+++ efi/arch/x86/platform/efi/efi.c
@@ -789,35 +789,13 @@ void __init old_map_region(efi_memory_de
pr_err("ioremap of 0x%llX failed!\n",
(unsigned long long)md->phys_addr);
}
-/*
- * This function will switch the EFI runtime services to virtual mode.
- * Essentially, look through the EFI memmap and map every region that
- * has the runtime attribute bit set in its memory descriptor and update
- * that memory descriptor with the virtual address obtained from ioremap().
- * This enables the runtime services to be called without having to
- * thunk back into physical mode for every invocation.
- */
-void __init efi_enter_virtual_mode(void)
-{
- 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 */
+static void efi_merge_regions(void)
+{
+ void *p;
+ efi_memory_desc_t *md, *prev_md = NULL;
- /* 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;
@@ -844,6 +822,19 @@ void __init efi_enter_virtual_mode(void)
prev_md = md;
}
+}
+
+/*
+ * Map efi memory ranges for runtime serivce
+ * Return the new memmap with updated virtual addrresses.
+ */
+void efi_map_regions(void **new_memmap, int *count)
+{
+ efi_memory_desc_t *md, *prev_md = NULL;
+ void *p;
+ unsigned long size;
+ efi_status_t status;
+ u64 end, systab;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
@@ -862,14 +853,44 @@ void __init efi_enter_virtual_mode(void)
systab += md->virt_addr - md->phys_addr;
efi.systab = (efi_system_table_t *) (unsigned long) systab;
}
- new_memmap = krealloc(new_memmap,
- (count + 1) * memmap.desc_size,
+ *new_memmap = krealloc(*new_memmap,
+ (*count + 1) * memmap.desc_size,
GFP_KERNEL);
- memcpy(new_memmap + (count * memmap.desc_size), md,
+ memcpy(*new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
- count++;
+ (*count)++;
+ }
+}
+
+/*
+ * This function will switch the EFI runtime services to virtual mode.
+ * Essentially, look through the EFI memmap and map every region that
+ * has the runtime attribute bit set in its memory descriptor and update
+ * that memory descriptor with the virtual address obtained from ioremap().
+ * This enables the runtime services to be called without having to
+ * thunk back into physical mode for every invocation.
+ */
+void __init efi_enter_virtual_mode(void)
+{
+ efi_status_t status;
+ void *p, *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();
+
+ efi_map_regions(&new_memmap, &count);
+
#ifdef CONFIG_X86_64
efi_scratch.efi_pgt = (pgd_t *)(unsigned long)real_mode_header->trampoline_pgd;
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-28 10:10 ` Dave Young
@ 2013-10-28 10:39 ` Dave Young
2013-10-28 11:20 ` Borislav Petkov
1 sibling, 0 replies; 36+ messages in thread
From: Dave Young @ 2013-10-28 10:39 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On 10/28/13 at 06:10pm, Dave Young wrote:
> On 10/28/13 at 11:04am, Borislav Petkov wrote:
> > On Mon, Oct 28, 2013 at 05:51:17PM +0800, Dave Young wrote:
> > > It does have a warning, but it applied successfully, no idea though:
> > > patches/02-efi-enter-virtual-mode-cleanup.patch
> > > Applying: Cleanup efi_enter_virtual_mode function
> > > /home/dave/git/efi/.git/rebase-apply/patch:42: space before tab in indent.
> > > efi_memory_desc_t *md, *prev_md = NULL;
> > > warning: 1 line adds whitespace errors.
> >
> > Hmm, ok, can you upload the patches somewhere so that I can pull them?
>
> Sorry, I have not any public git account. Attached the patch I applied with git
Here is the kernel patche files if you would like to try,
I have not got time to update them based on comments.
https://people.redhat.com/ruyang/kexec-efi/for-bp/kernel-patches/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-28 10:10 ` Dave Young
2013-10-28 10:39 ` Dave Young
@ 2013-10-28 11:20 ` Borislav Petkov
2013-10-28 11:24 ` Dave Young
1 sibling, 1 reply; 36+ messages in thread
From: Borislav Petkov @ 2013-10-28 11:20 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On Mon, Oct 28, 2013 at 06:10:11PM +0800, Dave Young wrote:
> Sorry, I have not any public git account. Attached the patch I applied
> with git
Still doesn't work:
$ patch -p1 --dry-run -i /tmp/02-efi-enter-virtual-mode-cleanup-1.patch.new
checking file arch/x86/platform/efi/efi.c
Hunk #1 succeeded at 788 (offset -1 lines).
Hunk #2 succeeded at 821 (offset -1 lines).
Hunk #3 FAILED at 853.
1 out of 3 hunks FAILED
I'm using Matt's next branch + my efi runtime branch. What are you
basing your stuff ontop?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-28 11:20 ` Borislav Petkov
@ 2013-10-28 11:24 ` Dave Young
2013-10-28 14:58 ` Borislav Petkov
0 siblings, 1 reply; 36+ messages in thread
From: Dave Young @ 2013-10-28 11:24 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On 10/28/13 at 12:20pm, Borislav Petkov wrote:
> On Mon, Oct 28, 2013 at 06:10:11PM +0800, Dave Young wrote:
> > Sorry, I have not any public git account. Attached the patch I applied
> > with git
>
> Still doesn't work:
>
> $ patch -p1 --dry-run -i /tmp/02-efi-enter-virtual-mode-cleanup-1.patch.new
> checking file arch/x86/platform/efi/efi.c
> Hunk #1 succeeded at 788 (offset -1 lines).
> Hunk #2 succeeded at 821 (offset -1 lines).
> Hunk #3 FAILED at 853.
> 1 out of 3 hunks FAILED
>
> I'm using Matt's next branch + my efi runtime branch. What are you
> basing your stuff ontop?
I use linus tree, git pull Matt's efi-next tree, then apply your 12 patches
and my patches. I applied your previous 11 patches + the last update patch
12/12, but the last one does not apply, I manually shift a hunk to make it
apply.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-28 11:24 ` Dave Young
@ 2013-10-28 14:58 ` Borislav Petkov
2013-10-28 15:10 ` Dave Young
0 siblings, 1 reply; 36+ messages in thread
From: Borislav Petkov @ 2013-10-28 14:58 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On Mon, Oct 28, 2013 at 07:24:58PM +0800, Dave Young wrote:
> I use linus tree, git pull Matt's efi-next tree, then apply your 12
> patches and my patches. I applied your previous 11 patches + the last
> update patch 12/12, but the last one does not apply, I manually shift
> a hunk to make it apply.
Nope, still doesn't apply.
patch -p1 --dry-run -i ~/efi/dy/03-efi-enter-virtual-mode-cleanup.patch
checking file arch/x86/platform/efi/efi.c
Hunk #1 succeeded at 788 (offset -1 lines).
Hunk #2 succeeded at 821 (offset -1 lines).
Hunk #3 FAILED at 853.
1 out of 3 hunks FAILED
and this time I took your patches from here: https://people.redhat.com/ruyang/kexec-efi/for-bp/kernel-patches/
What I did is:
1. I took Linus' tree from today
2. Merged the 'next' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git. Mind
you, not the 'efi-next' tag!
3. Then I merged the 'efi' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git ontop.
It gave a simple merge conflict which is trivial to resolve:
http://paste.debian.net/62579/
Here I started applying your patches and the 3rd one still fails.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-28 14:58 ` Borislav Petkov
@ 2013-10-28 15:10 ` Dave Young
2013-10-29 2:32 ` Dave Young
0 siblings, 1 reply; 36+ messages in thread
From: Dave Young @ 2013-10-28 15:10 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On 10/28/13 at 03:58pm, Borislav Petkov wrote:
> On Mon, Oct 28, 2013 at 07:24:58PM +0800, Dave Young wrote:
> > I use linus tree, git pull Matt's efi-next tree, then apply your 12
> > patches and my patches. I applied your previous 11 patches + the last
> > update patch 12/12, but the last one does not apply, I manually shift
> > a hunk to make it apply.
>
> Nope, still doesn't apply.
>
> patch -p1 --dry-run -i ~/efi/dy/03-efi-enter-virtual-mode-cleanup.patch
> checking file arch/x86/platform/efi/efi.c
> Hunk #1 succeeded at 788 (offset -1 lines).
> Hunk #2 succeeded at 821 (offset -1 lines).
> Hunk #3 FAILED at 853.
> 1 out of 3 hunks FAILED
>
> and this time I took your patches from here: https://people.redhat.com/ruyang/kexec-efi/for-bp/kernel-patches/
>
> What I did is:
>
> 1. I took Linus' tree from today
>
> 2. Merged the 'next' branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git. Mind
> you, not the 'efi-next' tag!
I used the above tree origin/next branch
>
> 3. Then I merged the 'efi' branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git ontop.
I used the patches from mailbox directly.
Fixed an conflict and merge them one by one.
> It gave a simple merge conflict which is trivial to resolve:
> http://paste.debian.net/62579/
Looks like I can not access above link.
>
> Here I started applying your patches and the 3rd one still fails.
>
It's strange to me. There must be something wrong in the steps
But sorry, it's time to sleep for me, will track this tommrrow.
Thanks
Dave
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-28 15:10 ` Dave Young
@ 2013-10-29 2:32 ` Dave Young
2013-10-29 13:43 ` Borislav Petkov
0 siblings, 1 reply; 36+ messages in thread
From: Dave Young @ 2013-10-29 2:32 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
> >
> > 3. Then I merged the 'efi' branch of
> > git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git ontop.
>
> I used the patches from mailbox directly.
> Fixed an conflict and merge them one by one.
I remember I tried your efi branch, but the code is different
from what you sent to list, thus I turned to use the mbox patches.
--
Thanks
Dave
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-29 2:32 ` Dave Young
@ 2013-10-29 13:43 ` Borislav Petkov
2013-10-30 2:03 ` Dave Young
0 siblings, 1 reply; 36+ messages in thread
From: Borislav Petkov @ 2013-10-29 13:43 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On Tue, Oct 29, 2013 at 10:32:03AM +0800, Dave Young wrote:
> I remember I tried your efi branch, but the code is different from
> what you sent to list, thus I turned to use the mbox patches.
Yeah, please use the #efi branch as I keep refreshing it with the newest
changes. They're hopefully not serious changes but minor stuff here and
there so basing stuff ontop should be ok.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-29 13:43 ` Borislav Petkov
@ 2013-10-30 2:03 ` Dave Young
2013-10-30 10:47 ` Borislav Petkov
0 siblings, 1 reply; 36+ messages in thread
From: Dave Young @ 2013-10-30 2:03 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On 10/29/13 at 02:43pm, Borislav Petkov wrote:
> On Tue, Oct 29, 2013 at 10:32:03AM +0800, Dave Young wrote:
> > I remember I tried your efi branch, but the code is different from
> > what you sent to list, thus I turned to use the mbox patches.
>
> Yeah, please use the #efi branch as I keep refreshing it with the newest
> changes. They're hopefully not serious changes but minor stuff here and
> there so basing stuff ontop should be ok.
Will try, but please keep the posted patches in mailing list up-to-date,
I'm an old-fashioned person, do not tend to depend on git.
Thanks in advance.
Dave
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-30 2:03 ` Dave Young
@ 2013-10-30 10:47 ` Borislav Petkov
2013-10-31 2:04 ` Dave Young
0 siblings, 1 reply; 36+ messages in thread
From: Borislav Petkov @ 2013-10-30 10:47 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On Wed, Oct 30, 2013 at 10:03:49AM +0800, Dave Young wrote:
> Will try, but please keep the posted patches in mailing list up-to-date,
Would you like me to send them to you privately?
> I'm an old-fashioned person, do not tend to depend on git.
Really? You should change that - you're missing out on so much by not
using git. :)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-30 10:47 ` Borislav Petkov
@ 2013-10-31 2:04 ` Dave Young
2013-10-31 2:07 ` Dave Young
0 siblings, 1 reply; 36+ messages in thread
From: Dave Young @ 2013-10-31 2:04 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On 10/30/13 at 11:47am, Borislav Petkov wrote:
> On Wed, Oct 30, 2013 at 10:03:49AM +0800, Dave Young wrote:
> > Will try, but please keep the posted patches in mailing list up-to-date,
>
> Would you like me to send them to you privately?
Thanks, do not bother to send me privately I can get it from your git tree.
But Frankly I'd like to see them in list instead even with only small fixes
beacuse in this way there might be more people to review it carefully.
--
Thanks
Dave
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-31 2:04 ` Dave Young
@ 2013-10-31 2:07 ` Dave Young
2013-10-31 3:07 ` H. Peter Anvin
2013-10-31 10:44 ` Borislav Petkov
0 siblings, 2 replies; 36+ messages in thread
From: Dave Young @ 2013-10-31 2:07 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On 10/31/13 at 10:04am, Dave Young wrote:
> On 10/30/13 at 11:47am, Borislav Petkov wrote:
> > On Wed, Oct 30, 2013 at 10:03:49AM +0800, Dave Young wrote:
> > > Will try, but please keep the posted patches in mailing list up-to-date,
> >
> > Would you like me to send them to you privately?
>
> Thanks, do not bother to send me privately I can get it from your git tree.
>
> But Frankly I'd like to see them in list instead even with only small fixes
> beacuse in this way there might be more people to review it carefully.
There's another shorcoming for keeping new patches in git is that nobody know
when you push it and when is the proper date to pull from your git. I think
it's better to use git only for the patches which have already been accepted
and is waiting for maintainer to pull.
>
> --
> Thanks
> Dave
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-31 2:07 ` Dave Young
@ 2013-10-31 3:07 ` H. Peter Anvin
2013-10-31 10:45 ` Borislav Petkov
2013-10-31 10:44 ` Borislav Petkov
1 sibling, 1 reply; 36+ messages in thread
From: H. Peter Anvin @ 2013-10-31 3:07 UTC (permalink / raw)
To: Dave Young, Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On 10/30/2013 07:07 PM, Dave Young wrote:
> On 10/31/13 at 10:04am, Dave Young wrote:
>> On 10/30/13 at 11:47am, Borislav Petkov wrote:
>>> On Wed, Oct 30, 2013 at 10:03:49AM +0800, Dave Young wrote:
>>>> Will try, but please keep the posted patches in mailing list up-to-date,
>>>
>>> Would you like me to send them to you privately?
>>
>> Thanks, do not bother to send me privately I can get it from your git tree.
>>
>> But Frankly I'd like to see them in list instead even with only small fixes
>> beacuse in this way there might be more people to review it carefully.
>
> There's another shorcoming for keeping new patches in git is that nobody know
> when you push it and when is the proper date to pull from your git. I think
> it's better to use git only for the patches which have already been accepted
> and is waiting for maintainer to pull.
>
You can use git for your own purposes, still.
-hpa
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-31 3:07 ` H. Peter Anvin
@ 2013-10-31 10:45 ` Borislav Petkov
2013-11-01 1:15 ` Dave Young
0 siblings, 1 reply; 36+ messages in thread
From: Borislav Petkov @ 2013-10-31 10:45 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Dave Young, linux-kernel, linux-efi, x86, mjg59, James.Bottomley,
vgoyal, ebiederm, horms, kexec, kexec
On Wed, Oct 30, 2013 at 08:07:45PM -0700, H. Peter Anvin wrote:
> You can use git for your own purposes, still.
git mk-coffee --refill --now
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-31 10:45 ` Borislav Petkov
@ 2013-11-01 1:15 ` Dave Young
0 siblings, 0 replies; 36+ messages in thread
From: Dave Young @ 2013-11-01 1:15 UTC (permalink / raw)
To: Borislav Petkov
Cc: H. Peter Anvin, linux-kernel, linux-efi, x86, mjg59,
James.Bottomley, vgoyal, ebiederm, horms, kexec, kexec, corbet
On 10/31/13 at 11:45am, Borislav Petkov wrote:
> On Wed, Oct 30, 2013 at 08:07:45PM -0700, H. Peter Anvin wrote:
> > You can use git for your own purposes, still.
>
> git mk-coffee --refill --now
Ccing Jonathan Corbet ;)
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-31 2:07 ` Dave Young
2013-10-31 3:07 ` H. Peter Anvin
@ 2013-10-31 10:44 ` Borislav Petkov
2013-11-01 1:18 ` Dave Young
1 sibling, 1 reply; 36+ messages in thread
From: Borislav Petkov @ 2013-10-31 10:44 UTC (permalink / raw)
To: Dave Young
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
Dear Mr. Young,
On Thu, Oct 31, 2013 at 10:07:14AM +0800, Dave Young wrote:
> > But Frankly I'd like to see them in list instead even with only small fixes
> > beacuse in this way there might be more people to review it carefully.
>
> There's another shorcoming for keeping new patches in git is that nobody know
> when you push it and when is the proper date to pull from your git. I think
> it's better to use git only for the patches which have already been accepted
> and is waiting for maintainer to pull.
thank you for teaching me how to do kernel development!
The actual and real reason why I didn't send them yet is because I
didn't want to be that kaffeine-inflated dork who spams the lists every
other day with a new version of his patches.
I am running build smoketests now and will send the latest version of
the patchset later today so don't worry, the world will see them :)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-10-31 10:44 ` Borislav Petkov
@ 2013-11-01 1:18 ` Dave Young
2013-11-01 11:32 ` Borislav Petkov
0 siblings, 1 reply; 36+ messages in thread
From: Dave Young @ 2013-11-01 1:18 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On 10/31/13 at 11:44am, Borislav Petkov wrote:
> Dear Mr. Young,
>
> On Thu, Oct 31, 2013 at 10:07:14AM +0800, Dave Young wrote:
> > > But Frankly I'd like to see them in list instead even with only small fixes
> > > beacuse in this way there might be more people to review it carefully.
> >
> > There's another shorcoming for keeping new patches in git is that nobody know
> > when you push it and when is the proper date to pull from your git. I think
> > it's better to use git only for the patches which have already been accepted
> > and is waiting for maintainer to pull.
>
> thank you for teaching me how to do kernel development!
>
> The actual and real reason why I didn't send them yet is because I
> didn't want to be that kaffeine-inflated dork who spams the lists every
> other day with a new version of his patches.
I need remind myself about careless patch, I used to do that before :(
>
> I am running build smoketests now and will send the latest version of
> the patchset later today so don't worry, the world will see them :)
Great, thank you. BTW, I have managed to test original patch set on a
Macboot Air of my friend with usb boot, it works ok.
--
Thanks
Dave
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
2013-11-01 1:18 ` Dave Young
@ 2013-11-01 11:32 ` Borislav Petkov
0 siblings, 0 replies; 36+ messages in thread
From: Borislav Petkov @ 2013-11-01 11:32 UTC (permalink / raw)
To: Dave Young
Cc: Borislav Petkov, linux-kernel, linux-efi, x86, mjg59, hpa,
James.Bottomley, vgoyal, ebiederm, horms, kexec, kexec
On Fri, Nov 01, 2013 at 09:18:25AM +0800, Dave Young wrote:
> Great, thank you. BTW, I have managed to test original patch set on a
> Macboot Air of my friend with usb boot, it works ok.
Ok, that's actually a very good news - the apples tend to be special wrt
uefi implementation.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 36+ messages in thread
* [patch 4/6] export more efi table variable to sysfs
2013-10-27 3:47 [patch 0/6] kexec kernel efi runtime support dyoung
2013-10-27 3:47 ` [patch 1/6] Add function efi_remap_region for remapping to saved virt address dyoung
2013-10-27 3:47 ` [patch 3/6] Cleanup efi_enter_virtual_mode function dyoung
@ 2013-10-27 3:47 ` dyoung
2013-10-27 3:47 ` [patch 5/6] export efi runtime memory mapping " dyoung
` (2 subsequent siblings)
5 siblings, 0 replies; 36+ messages in thread
From: dyoung @ 2013-10-27 3:47 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, kexec, bp, Dave Young
[-- Attachment #1: 03-export-more-efi-sysfs-vars.patch --]
[-- Type: text/plain, Size: 2253 bytes --]
Export fw_vendor, runtime and config tables physical
addresses to /sys/firmware/efi/systab becaue 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.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/platform/efi/efi.c | 4 ++++
drivers/firmware/efi/efi.c | 9 +++++++++
include/linux/efi.h | 3 +++
3 files changed, 16 insertions(+)
--- efi.orig/drivers/firmware/efi/efi.c
+++ efi/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_tables = EFI_INVALID_TABLE_ADDR,
};
EXPORT_SYMBOL(efi);
@@ -64,6 +67,12 @@ static ssize_t systab_show(struct kobjec
str += sprintf(str, "BOOTINFO=0x%lx\n", efi.boot_info);
if (efi.uga != EFI_INVALID_TABLE_ADDR)
str += sprintf(str, "UGA=0x%lx\n", efi.uga);
+ if (efi.fw_vendor!= EFI_INVALID_TABLE_ADDR)
+ str += sprintf(str, "fw_vendor=0x%lx\n", efi.fw_vendor);
+ if (efi.runtime!= EFI_INVALID_TABLE_ADDR)
+ str += sprintf(str, "runtime=0x%lx\n", efi.runtime);
+ if (efi.config_tables != EFI_INVALID_TABLE_ADDR)
+ str += sprintf(str, "config_tables=0x%lx\n", efi.config_tables);
return str - buf;
}
--- efi.orig/include/linux/efi.h
+++ efi/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;
+ unsigned long runtime;
+ unsigned long config_tables;
efi_get_time_t *get_time;
efi_set_time_t *set_time;
efi_get_wakeup_time_t *get_wakeup_time;
--- efi.orig/arch/x86/platform/efi/efi.c
+++ efi/arch/x86/platform/efi/efi.c
@@ -670,6 +670,10 @@ void __init efi_init(void)
set_bit(EFI_SYSTEM_TABLES, &x86_efi_facility);
+ efi.fw_vendor = (unsigned long)efi.systab->fw_vendor;
+ efi.runtime = (unsigned long)efi.systab->runtime;
+ efi.config_tables = (unsigned long)efi.systab->tables;
+
/*
* Show what we know for posterity
*/
^ permalink raw reply [flat|nested] 36+ messages in thread* [patch 5/6] export efi runtime memory mapping to sysfs
2013-10-27 3:47 [patch 0/6] kexec kernel efi runtime support dyoung
` (2 preceding siblings ...)
2013-10-27 3:47 ` [patch 4/6] export more efi table variable to sysfs dyoung
@ 2013-10-27 3:47 ` dyoung
2013-10-29 5:34 ` Dave Young
2013-10-27 3:47 ` [patch 6/6] passing kexec necessary efi data via setup_data dyoung
[not found] ` <20131027035922.924386710@dhcp-16-126.nay.redhat.com>
5 siblings, 1 reply; 36+ messages in thread
From: dyoung @ 2013-10-27 3:47 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, kexec, bp, Dave Young
[-- Attachment #1: 03-export-efi-runtime-mapping.patch --]
[-- Type: text/plain, Size: 8256 bytes --]
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 directly /sys/firmware/efi/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
It will not work for efi 32bit. Only x86_64 currently.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/include/asm/efi.h | 3
arch/x86/platform/efi/efi.c | 11 ++
drivers/firmware/efi/Kconfig | 10 +
drivers/firmware/efi/Makefile | 1
drivers/firmware/efi/efi-runtime-map.c | 166 +++++++++++++++++++++++++++++++++
drivers/firmware/efi/efi.c | 3
6 files changed, 193 insertions(+), 1 deletion(-)
--- linux-2.6.orig/arch/x86/platform/efi/efi.c
+++ linux-2.6/arch/x86/platform/efi/efi.c
@@ -57,6 +57,9 @@
#define EFI_MIN_RESERVE 5120
+efi_memory_desc_t *efi_runtime_map;
+int nr_efi_runtime_map;
+
/*
* We allocate runtime services regions bottom-up, starting from -4G, i.e.
* 0xffff_ffff_0000_0000 and limit EFI VA mapping space to 64G.
@@ -865,6 +868,14 @@ void efi_map_regions(void **new_memmap,
GFP_KERNEL);
memcpy(*new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
+ if (md->type != EFI_BOOT_SERVICES_CODE &&
+ md->type != EFI_BOOT_SERVICES_DATA) {
+ efi_runtime_map = krealloc(efi_runtime_map,
+ (nr_efi_runtime_map + 1) *
+ sizeof(efi_memory_desc_t), GFP_KERNEL);
+ *(efi_runtime_map + nr_efi_runtime_map) = *md;
+ nr_efi_runtime_map++;
+ }
(*count)++;
}
}
--- linux-2.6.orig/drivers/firmware/efi/Kconfig
+++ linux-2.6/drivers/firmware/efi/Kconfig
@@ -36,4 +36,14 @@ config EFI_VARS_PSTORE_DEFAULT_DISABLE
backend for pstore by default. This setting can be overridden
using the efivars module's pstore_disable parameter.
+config EFI_RUNTIME_MAP
+ bool "Add efi runtime map to sysfs" if EXPERT
+ default X86 && EFI
+ help
+ Add the efi runtime memory map 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-efi-runtime-map.
+
endmenu
--- linux-2.6.orig/drivers/firmware/efi/Makefile
+++ linux-2.6/drivers/firmware/efi/Makefile
@@ -4,3 +4,4 @@
obj-y += efi.o vars.o
obj-$(CONFIG_EFI_VARS) += efivars.o
obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o
+obj-$(CONFIG_EFI_RUNTIME_MAP) += efi-runtime-map.o
--- /dev/null
+++ linux-2.6/drivers/firmware/efi/efi-runtime-map.c
@@ -0,0 +1,166 @@
+/*
+ * linux/drivers/efi/efi-runtime-map.c
+ * Copyright (C) 2013 Red Hat, Inc., Dave Young <dyoung@redhat.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2.0 as published by
+ * the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/string.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/efi.h>
+#include <linux/slab.h>
+
+struct efi_runtime_map_entry {
+ efi_memory_desc_t md;
+ struct kobject kobj; /* kobject for each entry */
+};
+
+extern efi_memory_desc_t *efi_runtime_map;
+extern int nr_efi_runtime_map;
+struct efi_runtime_map_entry *map_entries;
+extern struct kobject *efi_kobj;
+
+static ssize_t map_attr_show(struct kobject *kobj,
+ struct attribute *attr, char *buf);
+static ssize_t type_show(struct efi_runtime_map_entry *entry, char *buf);
+static ssize_t phys_addr_show(struct efi_runtime_map_entry *entry, char *buf);
+static ssize_t virt_addr_show(struct efi_runtime_map_entry *entry, char *buf);
+static ssize_t num_pages_show(struct efi_runtime_map_entry *entry, char *buf);
+static ssize_t attribute_show(struct efi_runtime_map_entry *entry, char *buf);
+
+struct map_attribute {
+ struct attribute attr;
+ ssize_t (*show)(struct efi_runtime_map_entry *entry, char *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 inline struct efi_runtime_map_entry *
+to_map_entry(struct kobject *kobj)
+{
+ return container_of(kobj, struct efi_runtime_map_entry, kobj);
+}
+
+static struct kobj_type __refdata map_ktype = {
+ .sysfs_ops = &map_attr_ops,
+ .default_attrs = def_attrs,
+};
+
+/*
+ * Add map entry on sysfs
+ */
+static int add_sysfs_fw_map_entry(struct efi_runtime_map_entry *entry)
+{
+ static int map_entries_nr;
+ static struct kset *map_kset;
+
+ if (!map_kset) {
+ map_kset = kset_create_and_add("efi-runtime-map", NULL,
+ efi_kobj);
+ if (!map_kset)
+ return -ENOMEM;
+ }
+
+ kobject_init(&entry->kobj, &map_ktype);
+ entry->kobj.kset = map_kset;
+ if (kobject_add(&entry->kobj, NULL, "%d", map_entries_nr++))
+ kobject_put(&entry->kobj);
+
+ return 0;
+}
+
+static ssize_t type_show(struct efi_runtime_map_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%x\n", entry->md.type);
+}
+
+static ssize_t phys_addr_show(struct efi_runtime_map_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%llx\n", entry->md.phys_addr);
+}
+
+static ssize_t virt_addr_show(struct efi_runtime_map_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%llx\n", entry->md.virt_addr);
+}
+
+static ssize_t num_pages_show(struct efi_runtime_map_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%llx\n", entry->md.num_pages);
+}
+
+static ssize_t attribute_show(struct efi_runtime_map_entry *entry, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "0x%llx\n", entry->md.attribute);
+}
+
+static inline struct map_attribute *to_map_attr(struct attribute *attr)
+{
+ return container_of(attr, struct map_attribute, attr);
+}
+
+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 int __init efi_runtime_map_init(void)
+{
+ int i;
+ struct efi_runtime_map_entry *entry;
+ efi_memory_desc_t *md = efi_runtime_map;
+
+ if (!efi_runtime_map) {
+ pr_warning("no efi_runtime_map found\n");
+ return -EINVAL;
+ }
+
+ map_entries = kzalloc(nr_efi_runtime_map * sizeof(struct efi_runtime_map_entry), GFP_KERNEL);
+ if (!map_entries)
+ return -ENOMEM;
+ entry = map_entries;
+
+ for (i = 0; i < nr_efi_runtime_map; i++){
+ entry->md = *md;
+ add_sysfs_fw_map_entry(entry);
+ entry++;
+ md++;
+ }
+
+ return 0;
+}
+late_initcall(efi_runtime_map_init);
--- linux-2.6.orig/drivers/firmware/efi/efi.c
+++ linux-2.6/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;
/*
--- linux-2.6.orig/arch/x86/include/asm/efi.h
+++ linux-2.6/arch/x86/include/asm/efi.h
@@ -116,6 +116,9 @@ extern void __init efi_remap_region(efi_
extern void efi_sync_low_kernel_mappings(void);
extern void __init old_map_region(efi_memory_desc_t *md);
+extern efi_memory_desc_t *efi_runtime_map;
+extern int nr_efi_runtime_map;
+
#ifdef CONFIG_EFI
static inline bool efi_is_native(void)
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 5/6] export efi runtime memory mapping to sysfs
2013-10-27 3:47 ` [patch 5/6] export efi runtime memory mapping " dyoung
@ 2013-10-29 5:34 ` Dave Young
0 siblings, 0 replies; 36+ messages in thread
From: Dave Young @ 2013-10-29 5:34 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, kexec, bp
On 10/27/13 at 11:47am, 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 directly /sys/firmware/efi/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
>
> It will not work for efi 32bit. Only x86_64 currently.
>
> Signed-off-by: Dave Young <dyoung@redhat.com>
> ---
> arch/x86/include/asm/efi.h | 3
> arch/x86/platform/efi/efi.c | 11 ++
> drivers/firmware/efi/Kconfig | 10 +
> drivers/firmware/efi/Makefile | 1
> drivers/firmware/efi/efi-runtime-map.c | 166 +++++++++++++++++++++++++++++++++
> drivers/firmware/efi/efi.c | 3
> 6 files changed, 193 insertions(+), 1 deletion(-)
Remind myself: add below to Documentaion in next version:
Documentation/ABI/testing/sysfs-efi-runtime-map
^ permalink raw reply [flat|nested] 36+ messages in thread
* [patch 6/6] passing kexec necessary efi data via setup_data
2013-10-27 3:47 [patch 0/6] kexec kernel efi runtime support dyoung
` (3 preceding siblings ...)
2013-10-27 3:47 ` [patch 5/6] export efi runtime memory mapping " dyoung
@ 2013-10-27 3:47 ` dyoung
[not found] ` <20131027035922.924386710@dhcp-16-126.nay.redhat.com>
5 siblings, 0 replies; 36+ messages in thread
From: dyoung @ 2013-10-27 3:47 UTC (permalink / raw)
To: linux-kernel
Cc: linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal, ebiederm,
horms, kexec, kexec, bp, Dave Young
[-- Attachment #1: 05-use-efi-setup-data.patch --]
[-- Type: text/plain, Size: 8414 bytes --]
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 it need another variable
saving, it's the smbios physical address, the HP bios
also update the SMBIOS address after entering virtual mode
besides of the standard fw_vendor,runtime and config table.
Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
HP z420 workstation.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/include/asm/efi.h | 12 ++
arch/x86/include/uapi/asm/bootparam.h | 1
arch/x86/kernel/setup.c | 3
arch/x86/platform/efi/efi.c | 143 +++++++++++++++++++++++++++++-----
4 files changed, 142 insertions(+), 17 deletions(-)
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/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, data_len);
+ break;
default:
break;
}
--- linux-2.6.orig/arch/x86/platform/efi/efi.c
+++ linux-2.6/arch/x86/platform/efi/efi.c
@@ -59,6 +59,7 @@
efi_memory_desc_t *efi_runtime_map;
int nr_efi_runtime_map;
+struct efi_setup_data *esdata;
/*
* We allocate runtime services regions bottom-up, starting from -4G, i.e.
@@ -132,6 +133,32 @@ static int __init setup_storage_paranoia
}
early_param("efi_no_storage_paranoia", setup_storage_paranoia);
+void parse_efi_setup(u64 phys_addr, u32 data_len)
+{
+ int size;
+ struct setup_data *sdata;
+ u64 esdata_phys;
+
+ if (!efi_enabled(EFI_64BIT)) {
+ pr_warning("skipping setup_data on EFI 32BIT!");
+ return;
+ }
+
+ sdata = early_memremap(phys_addr, data_len);
+ if (!sdata)
+ return;
+
+ size = data_len - sizeof(struct setup_data);
+
+ esdata_phys = phys_addr + sizeof(struct setup_data);
+
+ nr_efi_runtime_map = (size - sizeof(struct efi_setup_data)) /
+ sizeof(efi_memory_desc_t);
+ early_iounmap(sdata, data_len);
+
+ /* setup data regions have been reserved by default */
+ esdata = phys_to_virt(esdata_phys);
+}
static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
{
@@ -521,8 +548,12 @@ static int __init efi_systab_init(void *
}
efi_systab.hdr = systab64->hdr;
- efi_systab.fw_vendor = systab64->fw_vendor;
- tmp |= systab64->fw_vendor;
+
+ if (esdata)
+ efi_systab.fw_vendor = (unsigned long)esdata->fw_vendor;
+ else
+ efi_systab.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;
@@ -536,13 +567,19 @@ static int __init efi_systab_init(void *
tmp |= systab64->stderr_handle;
efi_systab.stderr = systab64->stderr;
tmp |= systab64->stderr;
- efi_systab.runtime = (void *)(unsigned long)systab64->runtime;
- tmp |= systab64->runtime;
+ if (esdata)
+ efi_systab.runtime = (void *)(unsigned long)esdata->runtime;
+ else
+ efi_systab.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;
+ if (esdata)
+ efi_systab.tables = (unsigned long)esdata->tables;
+ else
+ efi_systab.tables = systab64->tables;
+ tmp |= efi_systab.tables;
early_iounmap(systab64, sizeof(*systab64));
#ifdef CONFIG_X86_32
@@ -648,6 +685,41 @@ static int __init efi_memmap_init(void)
return 0;
}
+static int __init efi_reuse_config(u64 tables, int nr_tables)
+{
+ void *p, *tablep;
+ int i, sz;
+
+ if (!efi_enabled(EFI_64BIT))
+ return 0;
+
+ 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");
+ return -ENOMEM;
+ }
+
+ for (i = 0; i < efi.systab->nr_tables; i++) {
+ efi_guid_t guid;
+
+ guid = ((efi_config_table_64_t *)p)->guid;
+
+ /*
+ HP z420 workstation smbios will be convert to
+ virtual address after enter virtual mode.
+ Thus in case kexec/kdump the physical address
+ will be passed in setup_data.
+ */
+ if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
+ ((efi_config_table_64_t *)p)->table = esdata->smbios;
+ p += sz;
+ }
+ early_iounmap(tablep, nr_tables * sz);
+ return 0;
+}
+
void __init efi_init(void)
{
efi_char16_t *c16;
@@ -693,6 +765,9 @@ void __init efi_init(void)
efi.systab->hdr.revision >> 16,
efi.systab->hdr.revision & 0xffff, vendor);
+ if (esdata && esdata->smbios)
+ efi_reuse_config(efi.systab->tables, efi.systab->nr_tables);
+
if (efi_config_init(arch_tables))
return;
@@ -837,10 +912,9 @@ static void efi_merge_regions(void)
*/
void efi_map_regions(void **new_memmap, int *count)
{
- efi_memory_desc_t *md, *prev_md = NULL;
+ efi_memory_desc_t *md;
void *p;
unsigned long size;
- efi_status_t status;
u64 end, systab;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
@@ -880,6 +954,34 @@ void efi_map_regions(void **new_memmap,
}
}
+void efi_remap_regions(void)
+{
+ int i;
+ unsigned long size;
+ efi_memory_desc_t *md;
+ u64 end, systab;
+
+ for (i = 0; i < nr_efi_runtime_map; i++) {
+ md = esdata->map + i;
+ efi_remap_region(md);
+ 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;
+ }
+ }
+
+ efi_runtime_map = kmalloc(nr_efi_runtime_map *
+ sizeof(efi_memory_desc_t), GFP_KERNEL);
+
+ memcpy(efi_runtime_map, esdata->map,
+ nr_efi_runtime_map * sizeof(efi_memory_desc_t));
+}
+
/*
* This function will switch the EFI runtime services to virtual mode.
* Essentially, look through the EFI memmap and map every region that
@@ -891,7 +993,7 @@ void efi_map_regions(void **new_memmap,
void __init efi_enter_virtual_mode(void)
{
efi_status_t status;
- void *p, *new_memmap = NULL;
+ void *new_memmap = NULL;
int count = 0;
efi.systab = NULL;
@@ -905,9 +1007,12 @@ void __init efi_enter_virtual_mode(void)
return;
}
- efi_merge_regions();
-
- efi_map_regions(&new_memmap, &count);
+ if (esdata)
+ efi_remap_regions();
+ else {
+ efi_merge_regions();
+ efi_map_regions(&new_memmap, &count);
+ }
#ifdef CONFIG_X86_64
efi_scratch.efi_pgt = (pgd_t *)(unsigned long)real_mode_header->trampoline_pgd;
@@ -920,11 +1025,14 @@ void __init efi_enter_virtual_mode(void)
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 (esdata)
+ status = EFI_SUCCESS;
+ else
+ 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 "
@@ -932,6 +1040,7 @@ void __init efi_enter_virtual_mode(void)
panic("EFI call to SetVirtualAddressMap() failed!");
}
+
/*
* Now that EFI is in virtual mode, update the function
* pointers in the runtime service table to the new virtual addresses.
--- linux-2.6.orig/arch/x86/include/uapi/asm/bootparam.h
+++ linux-2.6/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
--- linux-2.6.orig/arch/x86/include/asm/efi.h
+++ linux-2.6/arch/x86/include/asm/efi.h
@@ -119,6 +119,18 @@ extern void __init old_map_region(efi_me
extern efi_memory_desc_t *efi_runtime_map;
extern int nr_efi_runtime_map;
+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, u32 data_len);
+extern struct efi_setup_data *esdata;
+
#ifdef CONFIG_EFI
static inline bool efi_is_native(void)
^ permalink raw reply [flat|nested] 36+ messages in thread[parent not found: <20131027035922.924386710@dhcp-16-126.nay.redhat.com>]
* Re: [patch 2/6] x86 efi: reserve boot service fix
[not found] ` <20131027035922.924386710@dhcp-16-126.nay.redhat.com>
@ 2013-10-27 10:50 ` Borislav Petkov
2013-10-27 20:30 ` Matt Fleming
0 siblings, 1 reply; 36+ messages in thread
From: Borislav Petkov @ 2013-10-27 10:50 UTC (permalink / raw)
To: dyoung, Matt Fleming
Cc: linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley, vgoyal,
ebiederm, horms, kexec, kexec
On Sun, Oct 27, 2013 at 11:47:15AM +0800, dyoung@redhat.com wrote:
> 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>
Btw, Matt, this being a bugfix and all, shouldn't it be tagged for
stable?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 2/6] x86 efi: reserve boot service fix
2013-10-27 10:50 ` [patch 2/6] x86 efi: reserve boot service fix Borislav Petkov
@ 2013-10-27 20:30 ` Matt Fleming
2013-10-28 1:18 ` Dave Young
0 siblings, 1 reply; 36+ messages in thread
From: Matt Fleming @ 2013-10-27 20:30 UTC (permalink / raw)
To: Borislav Petkov
Cc: dyoung, linux-kernel, linux-efi, x86, mjg59, hpa, James.Bottomley,
vgoyal, ebiederm, horms, kexec, kexec
On Sun, 27 Oct, at 11:50:09AM, Borislav Petkov wrote:
> On Sun, Oct 27, 2013 at 11:47:15AM +0800, dyoung@redhat.com wrote:
> > 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>
>
> Btw, Matt, this being a bugfix and all, shouldn't it be tagged for
> stable?
Well that depends. Dave, am I correct in thinking that you only noticed
this bug when writing kexec support? I'm inclined not to bother with a
stable tag if no one has ever noticed any fallout from this bug until
now.
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [patch 2/6] x86 efi: reserve boot service fix
2013-10-27 20:30 ` Matt Fleming
@ 2013-10-28 1:18 ` Dave Young
2013-10-28 8:44 ` Borislav Petkov
0 siblings, 1 reply; 36+ messages in thread
From: Dave Young @ 2013-10-28 1:18 UTC (permalink / raw)
To: Matt Fleming
Cc: Borislav Petkov, linux-kernel, linux-efi, x86, mjg59, hpa,
James.Bottomley, vgoyal, ebiederm, horms, kexec, kexec
On 10/27/13 at 08:30pm, Matt Fleming wrote:
> On Sun, 27 Oct, at 11:50:09AM, Borislav Petkov wrote:
> > On Sun, Oct 27, 2013 at 11:47:15AM +0800, dyoung@redhat.com wrote:
> > > 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>
> >
> > Btw, Matt, this being a bugfix and all, shouldn't it be tagged for
> > stable?
>
> Well that depends. Dave, am I correct in thinking that you only noticed
> this bug when writing kexec support? I'm inclined not to bother with a
> stable tag if no one has ever noticed any fallout from this bug until
> now.
There should be some people see below message with non-kexec kernel:
"Could not reserve boot range ..."
But it's hard for them to notice the bad functionality because it's only
one mem range which might be not the boot range what SetVirtualAddressMap need
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [patch 2/6] x86 efi: reserve boot service fix
2013-10-28 1:18 ` Dave Young
@ 2013-10-28 8:44 ` Borislav Petkov
2013-10-28 10:27 ` Matt Fleming
0 siblings, 1 reply; 36+ messages in thread
From: Borislav Petkov @ 2013-10-28 8:44 UTC (permalink / raw)
To: Dave Young
Cc: Matt Fleming, linux-kernel, linux-efi, x86, mjg59, hpa,
James.Bottomley, vgoyal, ebiederm, horms, kexec, kexec
On Mon, Oct 28, 2013 at 09:18:24AM +0800, Dave Young wrote:
> There should be some people see below message with non-kexec kernel:
> "Could not reserve boot range ..."
I can find one other report like that: https://lkml.org/lkml/2013/7/16/309
[ 0.000000] efi: Could not reserve boot range [0x0000000000-0x0000000fff]
for
efi: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000001000) (0MB)
which is EFI_BOOT_SERVICES_CODE and
efi: Could not reserve boot range [0x000005f000-0x000009ffff]
for
efi: mem06: type=3, attr=0xf, range=[0x000000000005f000-0x00000000000a0000) (0MB)
which is of the same type.
> But it's hard for them to notice the bad functionality because
> it's only one mem range which might be not the boot range what
> SetVirtualAddressMap need
Right.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [patch 2/6] x86 efi: reserve boot service fix
2013-10-28 8:44 ` Borislav Petkov
@ 2013-10-28 10:27 ` Matt Fleming
0 siblings, 0 replies; 36+ messages in thread
From: Matt Fleming @ 2013-10-28 10:27 UTC (permalink / raw)
To: Borislav Petkov
Cc: Dave Young, linux-kernel, linux-efi, x86, mjg59, hpa,
James.Bottomley, vgoyal, ebiederm, horms, kexec, kexec
On Mon, 28 Oct, at 09:44:41AM, Borislav Petkov wrote:
> On Mon, Oct 28, 2013 at 09:18:24AM +0800, Dave Young wrote:
> > There should be some people see below message with non-kexec kernel:
> > "Could not reserve boot range ..."
>
> I can find one other report like that: https://lkml.org/lkml/2013/7/16/309
>
> [ 0.000000] efi: Could not reserve boot range [0x0000000000-0x0000000fff]
>
> for
>
> efi: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000001000) (0MB)
>
> which is EFI_BOOT_SERVICES_CODE and
>
> efi: Could not reserve boot range [0x000005f000-0x000009ffff]
>
> for
>
> efi: mem06: type=3, attr=0xf, range=[0x000000000005f000-0x00000000000a0000) (0MB)
>
> which is of the same type.
But that doesn't look like the issue that the user was complaining
about. Rather, it's that the higher EFI regions are unable to be mapped
because of the user's mem= kernel parameter setting.
However, even though this bug isn't the main focus of the above report,
since people are hitting it (and since the fix is trivial), I agree it's
worth tagging for stable.
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 36+ messages in thread