[patch 0/6] kexec kernel efi runtime support

[Dave Young]

Hi,

Here is the 1st version 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/systab, smbios is already in that file.

For efi runtime mapping I add a new directory /sys/firmware/efi/
efi-runtime-map/ like below
[dave@darkstar ~]$ tree /sys/firmware/efi/efi-runtime-map/
/sys/firmware/efi/efi-runtime-map/
├── 0
│   ├── attribute
│   ├── num_pages
│   ├── phys_addr
│   ├── type
│   └── virt_addr
├── 1
│   ├── attribute
│   ├── num_pages
│   ├── phys_addr
│   ├── type
│   └── virt_addr
[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

Please help to review the patches.

The patches are based on linus tree (3.12.0-rc6+) + matt's next tree + bp's efi
mapping patches
Boris's last patch can not directly apply, need a little line shifting.
--
Thanks
Dave

[patch 1/6] Add function efi_remap_region for remapping to saved virt address

[Dave Young]

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(a)redhat.com&gt;
---
 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;

[patch 1/6] Add function efi_remap_region for remapping to saved virt address

[Borislav Petkov]

On Sun, Oct 27, 2013 at 11:47:14AM +0800, dyoung(a)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(a)redhat.com&gt;
>  ---
>   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.
--

[patch 1/6] Add function efi_remap_region for remapping to saved virt address

[Dave Young]

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(a)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(a)redhat.com&gt;
>  > ---
>  >  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.
>  --

[patch 2/6] x86 efi: reserve boot service fix

[Dave Young]

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(a)redhat.com&gt;
---
 arch/x86/platform/efi/efi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- efi.orig/arch/x86/platform/efi/efi.c
+++ efi/arch/x86/platform/efi/efi.c
@@ -455,7 +455,7 @@ void __init efi_reserve_boot_services(vo
 		 * - 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)) {

[patch 2/6] x86 efi: reserve boot service fix

[Borislav Petkov]

On Sun, Oct 27, 2013 at 11:47:15AM +0800, dyoung(a)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(a)redhat.com&gt; 
Acked-by: Borislav Petkov <bp(a)suse.de&gt;

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

[patch 2/6] x86 efi: reserve boot service fix

[Matt Fleming]

On Sun, 27 Oct, at 11:50:09AM, Borislav Petkov wrote:
>  On Sun, Oct 27, 2013 at 11:47:15AM +0800, dyoung(a)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(a)redhat.com&gt;
>  
>  Acked-by: Borislav Petkov <bp(a)suse.de&gt;
>  
>  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

[patch 2/6] x86 efi: reserve boot service fix

[Dave Young]

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(a)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(a)redhat.com&gt;
>  > 
>  > Acked-by: Borislav Petkov <bp(a)suse.de&gt;
>  > 
>  > 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

[patch 2/6] x86 efi: reserve boot service fix

[Borislav Petkov]

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

[patch 2/6] x86 efi: reserve boot service fix

[Matt Fleming]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

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(a)redhat.com&gt;
---
 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;

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Borislav Petkov]

On Sun, Oct 27, 2013 at 11:47:16AM +0800, dyoung(a)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(a)redhat.com&gt;
>  ---
>   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.
--

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

On 10/28/13 at 10:32am, Borislav Petkov wrote:
>  On Sun, Oct 27, 2013 at 11:47:16AM +0800, dyoung(a)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(a)redhat.com&gt;
>  > ---
>  >  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.

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

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(a)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(a)redhat.com&gt;
>  > > ---
>  > >  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.

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Borislav Petkov]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

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/

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Borislav Petkov]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

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.

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Borislav Petkov]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Borislav Petkov]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Borislav Petkov]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[H. Peter Anvin]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Borislav Petkov]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Borislav Petkov]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Dave Young]

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

[patch 3/6] Cleanup efi_enter_virtual_mode function

[Borislav Petkov]

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

[patch 4/6] export more efi table variable to sysfs

[Dave Young]

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(a)redhat.com&gt;
---
 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
 	 */

[patch 5/6] export efi runtime memory mapping to sysfs

[Dave Young]

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(a)redhat.com&gt;
---
 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(a)redhat.com&gt;
+ *
+ * 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)

[patch 5/6] export efi runtime memory mapping to sysfs

[Dave Young]

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(a)redhat.com&gt;
>  ---
>   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

[patch 6/6] passing kexec necessary efi data via setup_data

[Dave Young]

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(a)redhat.com&gt;
---
 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)