Re: [PATCH -v2] EFI: Runtime services virtual mapping
Sorry for reply late because I was in a long holiday... On 09/30/13 at 10:17pm, Borislav Petkov wrote: On Thu, Sep 26, 2013 at 11:12:42AM +0800, Dave Young wrote: If we choose this approach, can we save not only the efi_mapping, but also the fields which will be converted to virt addr, like fw_vendor, runtime, tables? During my test on a HP workstation, the config table item (SMBIOS) also is converted to virt addr though spec only mention fw_vendor/runtime/tables. Btw, I was about to ask: how do you pass boot_params to the kexec kernel? As Vivek mentioned, just kexec-tools will get the saved info from sysfs or procfs, then it as a boot loader will prepare the linux boot setup struct with these 1st efi values. Because I'm looking into hpa's idea to pass an efi_mapping array of regions with setup_data but how does this get passed to the kexec'ed kernel? I see in your patches you have boot_params.saved_*** for the needed info but you're not writing to them anywhere. Is that why you've added them to the systab_show function so that userspace can parse it and build the boot_params thing? Yes, I just printed them in systab_show, kexec-tools will parse it. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
We can do that... but it is different from what Windows does to my understanding and it also has the potential of severe pathologies... e.g. a window at the top of the address space being mapped. Borislav Petkov b...@alien8.de wrote: On Wed, Oct 02, 2013 at 11:46:44AM -0700, H. Peter Anvin wrote: It's pretty straightforward - just drop the starting address to proper alignment after you subtract the size. Ok, just an observation - it is not necessarily a bad thing but I thought we should talk about it: So, when we do the VA space saving mapping, we're basically mapping huge physical ranges onto a much smaller VA range and adding other mappings in there pots-factum could turn out to be not straight-forward and problematic. To illustrate what I'm trying to say, here's an example from two regions in OVMF: [0.011005] __map_region: VA: 0xfffeff80..0x - PA: 0x80.. 0x100 [0.017005] __map_region: VA: 0xfffeff60..0xfffeff62 - PA: 0x7c00.. 0x7c02 Now, the physical address range spanned by those regions is: 0x7c02 - 0x80 = 0x7b82 =~ 2G while the virtual is 0x - 0xfffeff60 = 0xa0 =~ 10M Now, we obviously cannot map the whole PA space in there, the question is: do we care? I mean, we can map it to other VA range but this will totally destroy the simple math of computing EFI VA addresses with an offset, similar to PAGE_OFFSET. OTOH, if we keep Matt's suggestion of mapping the whole EFI address space window, we don't have that issue. And we've reserved 64G for EFI and if it needs more, we probably can give it since we're using a different pagetable anyway. Opinions? Thanks. -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On Fri, Oct 04, 2013 at 07:43:37AM -0700, H. Peter Anvin wrote: We can do that... but it is different from what Windows does to my understanding and it also has the potential of severe pathologies... e.g. a window at the top of the address space being mapped. Right, so after Matt and I talked about it a bit on IRC, we actually don't really care how we do the mappings if we spell them out later to kexec over proc or somewhere else, as you wanted. So we can do the VA address space saving scheme first and change it later, if there are issues. We'll see. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On 10/02/2013 10:05 AM, Borislav Petkov wrote: Btw, Matt just found another issue with the bottom-up approach - due to different alignment of VA and PA addresses, this messes up the pagetable in terms of the order in which we're using 4K, 2M, etc pages. What can happen is that, you can get a non-2M aligned PA mapped with 2M-aligned VA which results in a #PF with PF_RSVD set, which most likely happens because one or more of the bits in the [12:20] slice of the PMD are reserved but they get set due to the PA having address bits set in the aforementioned slice and thus a #PF is raised. So this is a bug in the sense that 2M pages were used when they were not safe to use (matching alignment is part of the requirement for 2M pages being allowable.) However, we of course want to use 2M pages, so see below. So we changed the mapping method to a more straight-forward one: we map all EFI regions in the following range: [ efi_va - -4G ] and we compute efi_va by subtracting the highest EFI region address from -4G, i.e. 0x___. Then, each VA is computed by doing efi_va + PA. Oh, and the alignment remains compatible this way. So this mapping scheme - courtesy of Matt - is very straight-forward and simple and I like simple. This way we won't need the setup_data games with kexec tools as we'll be simply doing the same mappings in the kexec'ed kernel. Anyway, I'll clean up the patch and send it out later. We could achieve the same thing by doing alignment after subtracting the pointer. HOWEVER, it also goes to show that any mapping scheme is inherently fragile (consider if the mapping scheme above ends up consuming too much virtual space in the future), and as a result I really think that explicitly passing the map to the kexec kernel really is the only sane thing to do, as otherwise we have to maintain the same algorithm forever. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On 10/02/2013 11:42 AM, Borislav Petkov wrote: Yes, so the alignment has to be such that both PA and VA are the same amount of 4K pages away from the next 2M boundary, to put it bluntly. I have a couple of ideas on how to do that. It's pretty straightforward - just drop the starting address to proper alignment after you subtract the size. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On Thu, Sep 26, 2013 at 11:12:42AM +0800, Dave Young wrote: If we choose this approach, can we save not only the efi_mapping, but also the fields which will be converted to virt addr, like fw_vendor, runtime, tables? During my test on a HP workstation, the config table item (SMBIOS) also is converted to virt addr though spec only mention fw_vendor/runtime/tables. Btw, I was about to ask: how do you pass boot_params to the kexec kernel? Because I'm looking into hpa's idea to pass an efi_mapping array of regions with setup_data but how does this get passed to the kexec'ed kernel? I see in your patches you have boot_params.saved_*** for the needed info but you're not writing to them anywhere. Is that why you've added them to the systab_show function so that userspace can parse it and build the boot_params thing? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On Mon, Sep 30, 2013 at 10:17:30PM +0200, Borislav Petkov wrote: On Thu, Sep 26, 2013 at 11:12:42AM +0800, Dave Young wrote: If we choose this approach, can we save not only the efi_mapping, but also the fields which will be converted to virt addr, like fw_vendor, runtime, tables? During my test on a HP workstation, the config table item (SMBIOS) also is converted to virt addr though spec only mention fw_vendor/runtime/tables. Btw, I was about to ask: how do you pass boot_params to the kexec kernel? kexec-tools in user space prepares the boot_params and passes it to second kernel. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On 09/24/2013 07:56 AM, Borislav Petkov wrote:
On Tue, September 24, 2013 2:45 pm, Dave Young wrote:
Think again about this, how about 1:1 map them from a base address
like -64G phy_addr - (-64G + phy_addr), in this way we can avoid
depending on the previous region size.
Right, how we layout the regions is arbitrary as long as we start at
the same VA and use the same regions, in the same order and of the same
size...
For the zero region problem, we can resolve it as a standalone
problem.
... however, we still need to understand why it fails mapping the boot
services region as some implementations apparently do call boot services
even after ExitBootServices(). IOW, we need that region mapped in the
kexec'ed kernel too.
I am starting to think that we really should explicitly pass along the
EFI mappings to the secondary kernel. This will also help if we have to
change the algorithm in a future kernel.
The most logical way to do this is to define a new setup_data type and
pass the entire set of physical-to-virtual mappings that way.
For example:
struct efi_mapping {
u64 va; /* Virtual start address */
u64 pa; /* Physical start address */
u64 len;/* Length in bytes */
u64 type; /* Mapping type */
u64 reserved[3];/* Reserved, must be zero */
};
Adding some reserved fields seems like a prudent precaution; the map
shouldn't be all that large anyway.
-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On 09/24/13 at 04:56pm, Borislav Petkov wrote: On Tue, September 24, 2013 2:45 pm, Dave Young wrote: Think again about this, how about 1:1 map them from a base address like -64G phy_addr - (-64G + phy_addr), in this way we can avoid depending on the previous region size. Right, how we layout the regions is arbitrary as long as we start at the same VA and use the same regions, in the same order and of the same size... For the zero region problem, we can resolve it as a standalone problem. ... however, we still need to understand why it fails mapping the boot services region as some implementations apparently do call boot services even after ExitBootServices(). IOW, we need that region mapped in the kexec'ed kernel too. In 1st kernel, the memmap is provided by firmware and unchanged before we do the mapping, later efi_reserve_boot_services() try to reserve the mem range, but failed due to conflict with other region (why?), then the memmap item size is set to 0 (why?). In 2nd kernel, we use same memmap from firmware, but the boot service ranges size have been set to 0, thus efi mapping code will mapping runtime regions to different va from 1st kernel. -- Thanks Dave -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On 09/21/13 at 01:39pm, Borislav Petkov wrote:
On Thu, Sep 19, 2013 at 04:54:54PM +0200, Borislav Petkov wrote:
From: Borislav Petkov b...@suse.de
We map the EFI regions needed for runtime services contiguously on
virtual addresses starting from -4G down for a total max space of 64G.
This way, we provide for stable runtime services addresses across
kernels so that a kexec'd kernel can still use them.
This way, they're mapped in a separate pagetable so that we don't
pollute the kernel namespace (you can see how the whole ioremapping and
saving and restoring of PGDs is gone now).
Ok, this one was not so good, let's try again:
This time I saved 32-bit and am switching the pagetable only after
having built it properly. This boots fine again on baremetal and on OVMF
with Matt's handover flags fix from yesterday.
Also, I've uploaded the whole series to
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git, branch
efi-experimental
(-experimental doesn't trigger Fengguang's robot :-))
Good luck! :-)
---
From 880fcee20209a122eda846e7f109776ed1c56de5 Mon Sep 17 00:00:00 2001
From: Borislav Petkov b...@suse.de
Date: Wed, 18 Sep 2013 17:35:42 +0200
Subject: [PATCH] EFI: Runtime services virtual mapping
We map the EFI regions needed for runtime services contiguously on
virtual addresses starting from -4G down for a total max space of 64G.
This way, we provide for stable runtime services addresses across
kernels so that a kexec'd kernel can still use them.
This way, they're mapped in a separate pagetable so that we don't
pollute the kernel namespace (you can see how the whole ioremapping and
saving and restoring of PGDs is gone now).
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/include/asm/efi.h | 43 ++
arch/x86/include/asm/pgtable_types.h | 3 +-
arch/x86/platform/efi/efi.c | 68 -
arch/x86/platform/efi/efi_32.c | 29 +++-
arch/x86/platform/efi/efi_64.c | 85
+++-
arch/x86/platform/efi/efi_stub_64.S | 53 ++
6 files changed, 181 insertions(+), 100 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 0062a0125041..9a99e0499e4b 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -69,24 +69,31 @@ extern u64 efi_call6(void *fp, u64 arg1, u64 arg2, u64
arg3,
efi_call6((f), (u64)(a1), (u64)(a2), (u64)(a3), \
(u64)(a4), (u64)(a5), (u64)(a6))
+#define _efi_call_virtX(x, f, ...) \
+({ \
+ efi_status_t __s; \
+ \
+ efi_sync_low_kernel_mappings(); \
+ preempt_disable(); \
+ __s = efi_call##x((void *)efi.systab-runtime-f, __VA_ARGS__); \
+ preempt_enable(); \
+ __s;\
+})
+
#define efi_call_virt0(f)\
- efi_call0((efi.systab-runtime-f))
-#define efi_call_virt1(f, a1)\
- efi_call1((efi.systab-runtime-f), (u64)(a1))
-#define efi_call_virt2(f, a1, a2)\
- efi_call2((efi.systab-runtime-f), (u64)(a1), (u64)(a2))
-#define efi_call_virt3(f, a1, a2, a3)
\
- efi_call3((efi.systab-runtime-f), (u64)(a1), (u64)(a2), \
- (u64)(a3))
-#define efi_call_virt4(f, a1, a2, a3, a4)\
- efi_call4((efi.systab-runtime-f), (u64)(a1), (u64)(a2), \
- (u64)(a3), (u64)(a4))
-#define efi_call_virt5(f, a1, a2, a3, a4, a5)
\
- efi_call5((efi.systab-runtime-f), (u64)(a1), (u64)(a2), \
- (u64)(a3), (u64)(a4), (u64)(a5))
-#define efi_call_virt6(f, a1, a2, a3, a4, a5, a6)\
- efi_call6((efi.systab-runtime-f), (u64)(a1), (u64)(a2), \
- (u64)(a3), (u64)(a4), (u64)(a5), (u64)(a6))
+ _efi_call_virtX(0, f)
+#define efi_call_virt1(f, a1)\
+ _efi_call_virtX(1, f, (u64)(a1))
+#define efi_call_virt2(f, a1, a2)\
+ _efi_call_virtX(2, f, (u64)(a1), (u64)(a2))
+#define efi_call_virt3(f, a1, a2, a3)\
+ _efi_call_virtX(3, f, (u64)(a1), (u64)(a2), (u64)(a3))
+#define efi_call_virt4(f, a1, a2, a3, a4)\
+ _efi_call_virtX(4, f, (u64)(a1), (u64)(a2), (u64)(a3), (u64)(a4))
+#define efi_call_virt5(f, a1, a2, a3, a4, a5)\
+ _efi_call_virtX(5, f, (u64)(a1), (u64)(a2), (u64)(a3),
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On Mon, Sep 23, 2013 at 01:47:41PM +0800, Dave Young wrote:
+ unsigned long size = md-num_pages PAGE_SHIFT;
+
+ efi_va -= size;
+ if (efi_va EFI_VA_END) {
+ pr_warning(FW_WARN VA address range overflow!\n);
+ return;
+ }
+
+ /* Do the 1:1 map */
+ __map_region(md, md-phys_addr);
+
+ /* Do the VA map */
+ __map_region(md, efi_va);
Could you add comment for above code? It's hard to understand the
twice mapping if one did not follow the old thread.
Does that suffice:
/*
* Make sure the 1:1 mappings are present as a catch-all for b0rked firmware
* which doesn't update all internal pointers after switching to virtual mode
* and would otherwise crap on us.
*/
?
Btw, when you reply to a mail, please remove that quoted portion of it
which you're not replying to - I had to scroll a bunch of screens down
and I almost missed your reply. :)
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On Sat, Sep 21, 2013 at 01:39:29PM +0200, Borislav Petkov wrote: -void __init efi_call_phys_prelog(void) +/* + * We allocate runtime services regions top-down, starting from -4G, i.e. + * 0x___ and limit EFI VA mapping space to 64G. + */ +static u64 efi_va = -4 * (1UL 30); +#define EFI_VA_END(-68 * (1UL 30)) Note to self: add this range to Documentation/x86/x86_64/mm.txt -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On 09/22/13 at 08:27am, H. Peter Anvin wrote: The address that faults is interesting in that it is indeed just below -4G. The question at hand is probably what information you are using to build the EFI mappings in the secondary kernel and what could make it not match the primary. Assuming it isn't as simple as the mappings never get built at all. Here is my debug output, diff efi-mapping-1st-kernel efi-mapping-2nd-kernel: Obviously, the high address mapping is not same: --- efi-mapping-1.txt 2013-09-24 10:46:09.977746047 +0800 +++ efi-mapping-2.txt 2013-09-24 10:46:33.871421806 +0800 @@ -1,30 +1,30 @@ efi mapping PA 0x80 - VA 0x80 efi mapping PA 0x80 - VA 0x efi mapping PA 0x7c00 - VA 0x7c00 -efi mapping PA 0x7c00 - VA 0xfffefffe +efi mapping PA 0x7c00 - VA 0x efi mapping PA 0x7d5e2000 - VA 0x7d5e2000 -efi mapping PA 0x7d5e2000 - VA 0xfffefffdf000 +efi mapping PA 0x7d5e2000 - VA 0xfffef000 efi mapping PA 0x7d77d000 - VA 0x7d77d000 -efi mapping PA 0x7d77d000 - VA 0xfffefffde000 +efi mapping PA 0x7d77d000 - VA 0xfffee000 efi mapping PA 0x7d864000 - VA 0x7d864000 -efi mapping PA 0x7d864000 - VA 0xfffeff8d4000 +efi mapping PA 0x7d864000 - VA 0xfffeff8f4000 efi mapping PA 0x7df6e000 - VA 0x7df6e000 -efi mapping PA 0x7df6e000 - VA 0xfffeff6ae000 +efi mapping PA 0x7df6e000 - VA 0xfffeff6ce000 efi mapping PA 0x7e194000 - VA 0x7e194000 -efi mapping PA 0x7e194000 - VA 0xfffeff6ac000 +efi mapping PA 0x7e194000 - VA 0xfffeff6cc000 efi mapping PA 0x7e196000 - VA 0x7e196000 -efi mapping PA 0x7e196000 - VA 0xfffeff696000 +efi mapping PA 0x7e196000 - VA 0xfffeff6b6000 efi mapping PA 0x7e1ac000 - VA 0x7e1ac000 -efi mapping PA 0x7e1ac000 - VA 0xfffeff681000 +efi mapping PA 0x7e1ac000 - VA 0xfffeff6a1000 efi mapping PA 0x7e1c1000 - VA 0x7e1c1000 -efi mapping PA 0x7e1c1000 - VA 0xfffefe041000 +efi mapping PA 0x7e1c1000 - VA 0xfffefe061000 efi mapping PA 0x7f802000 - VA 0x7f802000 -efi mapping PA 0x7f802000 - VA 0xfffefdec2000 +efi mapping PA 0x7f802000 - VA 0xfffefdee2000 efi mapping PA 0x7f981000 - VA 0x7f981000 -efi mapping PA 0x7f981000 - VA 0xfffefde92000 +efi mapping PA 0x7f981000 - VA 0xfffefdeb2000 efi mapping PA 0x7f9b1000 - VA 0x7f9b1000 -efi mapping PA 0x7f9b1000 - VA 0xfffefde6e000 +efi mapping PA 0x7f9b1000 - VA 0xfffefde8e000 efi mapping PA 0x7f9e5000 - VA 0x7f9e5000 -efi mapping PA 0x7f9e5000 - VA 0xfffefd873000 +efi mapping PA 0x7f9e5000 - VA 0xfffefd893000 efi mapping PA 0x7ffe - VA 0x7ffe -efi mapping PA 0x7ffe - VA 0xfffefd853000 +efi mapping PA 0x7ffe - VA 0xfffefd873000 Borislav Petkov b...@alien8.de wrote: On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote: I tested your new patch, it works both with efi stub and grub boot in 1st kernel. Good, thanks! But it paniced in kexec boot with my kexec related patcheset, the patchset That's the second kernel, right? contains 3 patch: 1. introduce cmdline kexecboot=0|1|2; 1 == kexec, 2 == kdump 2. export physical addr fw_vendor, runtime, tables to /sys/firmware/efi/systab 3. if kexecboot != 0, use fw_vendor, runtime, tables from bootparams; Also do not call SetVirtualAddressMao in case kexecboot. The panic happens at the last line of efi_init: /* clean DUMMY object */ efi.set_variable(efi_dummy_name, EFI_DUMMY_GUID, EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, 0, NULL); Below is the dmesg: [0.003359] pid_max: default: 32768 minimum: 301 [0.004792] BUG: unable to handle kernel paging request at fffefde97e70 [0.00] IP: [8103a1db] virt_efi_set_variable+0x40/0x54 [0.00] PGD 36981067 PUD 35828063 PMD 0 Here it is - fffefde97e70 is not mapped in the pagetable, PMD is 0. Ok, can you upload your patches somewhere and tell me exactly how to reproduce this so that I can take a look too? Thanks. -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On 09/23/13 at 08:06pm, H. Peter Anvin wrote:
Okay... I see two problems.
1. It looks like we subtract the region size after, rather than before,
assigning an address.
2. The second region is assigned the same address in the secondary kernel as
in the first, implying the size of the first region was somehow set to zero.
I find the reason, efi_reserve_boot_services will reserve the BOOT_SERVICE_DATA
region
thus the memmap size is changed to 0, so in 2nd kernel the virtual mapping addr
after
the md will be not same as 1st kernel, see below code:
void __init efi_map_region(efi_memory_desc_t *md)
{
unsigned long size = md-num_pages PAGE_SHIFT;
efi_va -= size;
^^^
[snip]
}
Dave Young dyo...@redhat.com wrote:
On 09/22/13 at 08:27am, H. Peter Anvin wrote:
The address that faults is interesting in that it is indeed just
below -4G. The question at hand is probably what information you are
using to build the EFI mappings in the secondary kernel and what could
make it not match the primary.
Assuming it isn't as simple as the mappings never get built at all.
Here is my debug output, diff efi-mapping-1st-kernel
efi-mapping-2nd-kernel:
Obviously, the high address mapping is not same:
--- efi-mapping-1.txt2013-09-24 10:46:09.977746047 +0800
+++ efi-mapping-2.txt2013-09-24 10:46:33.871421806 +0800
@@ -1,30 +1,30 @@
efi mapping PA 0x80 - VA 0x80
efi mapping PA 0x80 - VA 0x
efi mapping PA 0x7c00 - VA 0x7c00
-efi mapping PA 0x7c00 - VA 0xfffefffe
+efi mapping PA 0x7c00 - VA 0x
efi mapping PA 0x7d5e2000 - VA 0x7d5e2000
-efi mapping PA 0x7d5e2000 - VA 0xfffefffdf000
+efi mapping PA 0x7d5e2000 - VA 0xfffef000
efi mapping PA 0x7d77d000 - VA 0x7d77d000
-efi mapping PA 0x7d77d000 - VA 0xfffefffde000
+efi mapping PA 0x7d77d000 - VA 0xfffee000
efi mapping PA 0x7d864000 - VA 0x7d864000
-efi mapping PA 0x7d864000 - VA 0xfffeff8d4000
+efi mapping PA 0x7d864000 - VA 0xfffeff8f4000
efi mapping PA 0x7df6e000 - VA 0x7df6e000
-efi mapping PA 0x7df6e000 - VA 0xfffeff6ae000
+efi mapping PA 0x7df6e000 - VA 0xfffeff6ce000
efi mapping PA 0x7e194000 - VA 0x7e194000
-efi mapping PA 0x7e194000 - VA 0xfffeff6ac000
+efi mapping PA 0x7e194000 - VA 0xfffeff6cc000
efi mapping PA 0x7e196000 - VA 0x7e196000
-efi mapping PA 0x7e196000 - VA 0xfffeff696000
+efi mapping PA 0x7e196000 - VA 0xfffeff6b6000
efi mapping PA 0x7e1ac000 - VA 0x7e1ac000
-efi mapping PA 0x7e1ac000 - VA 0xfffeff681000
+efi mapping PA 0x7e1ac000 - VA 0xfffeff6a1000
efi mapping PA 0x7e1c1000 - VA 0x7e1c1000
-efi mapping PA 0x7e1c1000 - VA 0xfffefe041000
+efi mapping PA 0x7e1c1000 - VA 0xfffefe061000
efi mapping PA 0x7f802000 - VA 0x7f802000
-efi mapping PA 0x7f802000 - VA 0xfffefdec2000
+efi mapping PA 0x7f802000 - VA 0xfffefdee2000
efi mapping PA 0x7f981000 - VA 0x7f981000
-efi mapping PA 0x7f981000 - VA 0xfffefde92000
+efi mapping PA 0x7f981000 - VA 0xfffefdeb2000
efi mapping PA 0x7f9b1000 - VA 0x7f9b1000
-efi mapping PA 0x7f9b1000 - VA 0xfffefde6e000
+efi mapping PA 0x7f9b1000 - VA 0xfffefde8e000
efi mapping PA 0x7f9e5000 - VA 0x7f9e5000
-efi mapping PA 0x7f9e5000 - VA 0xfffefd873000
+efi mapping PA 0x7f9e5000 - VA 0xfffefd893000
efi mapping PA 0x7ffe - VA 0x7ffe
-efi mapping PA 0x7ffe - VA 0xfffefd853000
+efi mapping PA 0x7ffe - VA 0xfffefd873000
Borislav Petkov b...@alien8.de wrote:
On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote:
I tested your new patch, it works both with efi stub and grub boot
in
1st kernel.
Good, thanks!
But it paniced in kexec boot with my kexec related patcheset, the
patchset
That's the second kernel, right?
contains 3 patch:
1. introduce cmdline kexecboot=0|1|2; 1 == kexec, 2 == kdump
2. export physical addr fw_vendor, runtime, tables to
/sys/firmware/efi/systab
3. if kexecboot != 0, use fw_vendor, runtime, tables from
bootparams;
Also do not
call SetVirtualAddressMao in case kexecboot.
The panic happens at the last line of efi_init:
/* clean DUMMY object */
efi.set_variable(efi_dummy_name, EFI_DUMMY_GUID,
EFI_VARIABLE_NON_VOLATILE |
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS,
0, NULL);
Below is the dmesg:
[0.003359] pid_max: default: 32768 minimum: 301
[0.004792] BUG: unable to handle kernel paging request at
fffefde97e70
[0.00] IP: [8103a1db]
virt_efi_set_variable+0x40/0x54
[0.00] PGD 36981067 PUD 35828063 PMD 0
Here it is - fffefde97e70 is not mapped in the pagetable, PMD is
0.
Ok, can you upload
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On 09/24/13 at 12:58pm, Dave Young wrote:
On 09/24/13 at 12:57pm, Dave Young wrote:
On 09/23/13 at 08:06pm, H. Peter Anvin wrote:
Okay... I see two problems.
1. It looks like we subtract the region size after, rather than before,
assigning an address.
Could you explain more about this problem? Where is the code?
2. The second region is assigned the same address in the secondary kernel
as in the first, implying the size of the first region was somehow set to
zero.
I find the reason, efi_reserve_boot_services will reserve the
BOOT_SERVICE_DATA region
thus the memmap size is changed to 0, so in 2nd kernel the virtual mapping
addr after
the md will be not same as 1st kernel, see below code:
void __init efi_map_region(efi_memory_desc_t *md)
{
unsigned long size = md-num_pages PAGE_SHIFT;
efi_va -= size;
^^^
[snip]
}
So how about just reserve BOOT_SERVICE_DATA region but keep the md.numpages
as is?
Hmm, num_pages = 0 is only set when boot service region reservation is
imporsible, I'm
lost.. But there must be somewhere set the size to 0.
Dave Young dyo...@redhat.com wrote:
On 09/22/13 at 08:27am, H. Peter Anvin wrote:
The address that faults is interesting in that it is indeed just
below -4G. The question at hand is probably what information you are
using to build the EFI mappings in the secondary kernel and what could
make it not match the primary.
Assuming it isn't as simple as the mappings never get built at all.
Here is my debug output, diff efi-mapping-1st-kernel
efi-mapping-2nd-kernel:
Obviously, the high address mapping is not same:
--- efi-mapping-1.txt2013-09-24 10:46:09.977746047 +0800
+++ efi-mapping-2.txt2013-09-24 10:46:33.871421806 +0800
@@ -1,30 +1,30 @@
efi mapping PA 0x80 - VA 0x80
efi mapping PA 0x80 - VA 0x
efi mapping PA 0x7c00 - VA 0x7c00
-efi mapping PA 0x7c00 - VA 0xfffefffe
+efi mapping PA 0x7c00 - VA 0x
efi mapping PA 0x7d5e2000 - VA 0x7d5e2000
-efi mapping PA 0x7d5e2000 - VA 0xfffefffdf000
+efi mapping PA 0x7d5e2000 - VA 0xfffef000
efi mapping PA 0x7d77d000 - VA 0x7d77d000
-efi mapping PA 0x7d77d000 - VA 0xfffefffde000
+efi mapping PA 0x7d77d000 - VA 0xfffee000
efi mapping PA 0x7d864000 - VA 0x7d864000
-efi mapping PA 0x7d864000 - VA 0xfffeff8d4000
+efi mapping PA 0x7d864000 - VA 0xfffeff8f4000
efi mapping PA 0x7df6e000 - VA 0x7df6e000
-efi mapping PA 0x7df6e000 - VA 0xfffeff6ae000
+efi mapping PA 0x7df6e000 - VA 0xfffeff6ce000
efi mapping PA 0x7e194000 - VA 0x7e194000
-efi mapping PA 0x7e194000 - VA 0xfffeff6ac000
+efi mapping PA 0x7e194000 - VA 0xfffeff6cc000
efi mapping PA 0x7e196000 - VA 0x7e196000
-efi mapping PA 0x7e196000 - VA 0xfffeff696000
+efi mapping PA 0x7e196000 - VA 0xfffeff6b6000
efi mapping PA 0x7e1ac000 - VA 0x7e1ac000
-efi mapping PA 0x7e1ac000 - VA 0xfffeff681000
+efi mapping PA 0x7e1ac000 - VA 0xfffeff6a1000
efi mapping PA 0x7e1c1000 - VA 0x7e1c1000
-efi mapping PA 0x7e1c1000 - VA 0xfffefe041000
+efi mapping PA 0x7e1c1000 - VA 0xfffefe061000
efi mapping PA 0x7f802000 - VA 0x7f802000
-efi mapping PA 0x7f802000 - VA 0xfffefdec2000
+efi mapping PA 0x7f802000 - VA 0xfffefdee2000
efi mapping PA 0x7f981000 - VA 0x7f981000
-efi mapping PA 0x7f981000 - VA 0xfffefde92000
+efi mapping PA 0x7f981000 - VA 0xfffefdeb2000
efi mapping PA 0x7f9b1000 - VA 0x7f9b1000
-efi mapping PA 0x7f9b1000 - VA 0xfffefde6e000
+efi mapping PA 0x7f9b1000 - VA 0xfffefde8e000
efi mapping PA 0x7f9e5000 - VA 0x7f9e5000
-efi mapping PA 0x7f9e5000 - VA 0xfffefd873000
+efi mapping PA 0x7f9e5000 - VA 0xfffefd893000
efi mapping PA 0x7ffe - VA 0x7ffe
-efi mapping PA 0x7ffe - VA 0xfffefd853000
+efi mapping PA 0x7ffe - VA 0xfffefd873000
Borislav Petkov b...@alien8.de wrote:
On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote:
I tested your new patch, it works both with efi stub and grub boot
in
1st kernel.
Good, thanks!
But it paniced in kexec boot with my kexec related patcheset, the
patchset
That's the second kernel, right?
contains 3 patch:
1. introduce cmdline kexecboot=0|1|2; 1 == kexec, 2 == kdump
2. export physical addr fw_vendor, runtime, tables to
/sys/firmware/efi/systab
3. if kexecboot != 0, use fw_vendor, runtime, tables from
bootparams;
Also do not
call SetVirtualAddressMao in case kexecboot.
The panic happens at the last line of efi_init:
/* clean DUMMY object */
efi.set_variable(efi_dummy_name, EFI_DUMMY_GUID,
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On 09/21/13 at 01:39pm, Borislav Petkov wrote: On Thu, Sep 19, 2013 at 04:54:54PM +0200, Borislav Petkov wrote: From: Borislav Petkov b...@suse.de We map the EFI regions needed for runtime services contiguously on virtual addresses starting from -4G down for a total max space of 64G. This way, we provide for stable runtime services addresses across kernels so that a kexec'd kernel can still use them. This way, they're mapped in a separate pagetable so that we don't pollute the kernel namespace (you can see how the whole ioremapping and saving and restoring of PGDs is gone now). Ok, this one was not so good, let's try again: This time I saved 32-bit and am switching the pagetable only after having built it properly. This boots fine again on baremetal and on OVMF with Matt's handover flags fix from yesterday. Also, I've uploaded the whole series to git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git, branch efi-experimental I tested your new patch, it works both with efi stub and grub boot in 1st kernel. But it paniced in kexec boot with my kexec related patcheset, the patchset contains 3 patch: 1. introduce cmdline kexecboot=0|1|2; 1 == kexec, 2 == kdump 2. export physical addr fw_vendor, runtime, tables to /sys/firmware/efi/systab 3. if kexecboot != 0, use fw_vendor, runtime, tables from bootparams; Also do not call SetVirtualAddressMao in case kexecboot. The panic happens at the last line of efi_init: /* clean DUMMY object */ efi.set_variable(efi_dummy_name, EFI_DUMMY_GUID, EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, 0, NULL); Below is the dmesg: [0.003359] pid_max: default: 32768 minimum: 301 [0.004792] BUG: unable to handle kernel paging request at fffefde97e70 [0.00] IP: [8103a1db] virt_efi_set_variable+0x40/0x54 [0.00] PGD 36981067 PUD 35828063 PMD 0 [0.00] Oops: [#1] SMP [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0-rc1+ #10 [0.00] task: 81985490 ti: 81964000 task.ti: 81964000 [0.00] RIP: 0010:[8103a1db] [8103a1db] virt_efi_set_variable+0x40/0x54 [0.00] RSP: :81965ee0 EFLAGS: 00010246 [0.00] RAX: fffefde97e18 RBX: 81999300 RCX: 0007 [0.00] RDX: 81965f20 RSI: 81999300 RDI: 8809cc88 [0.00] RBP: 81965f08 R08: R09: [0.00] R10: R11: R12: 81965f20 [0.00] R13: R14: 0007 R15: [0.00] FS: () GS:880035c0() knlGS: [0.00] CS: 0010 DS: ES: CR0: 8005003b [0.00] CR2: fffefde97e70 CR3: 3698 CR4: 06b0 [0.00] Stack: [0.00] ff475630 88003582c000 000f [0.00] 000f 81965f60 81a98a7c 81b1a900 [0.00] 47ddbe4b4424ac57 a9929ff050ed979e a02eda84fa6789b9 [0.00] Call Trace: [0.00] [81a98a7c] efi_enter_virtual_mode+0x30a/0x32c [0.00] [81a83ccf] start_kernel+0x349/0x3da [0.00] [81a83794] ? repair_env_string+0x58/0x58 [0.00] [81a83120] ? early_idt_handlers+0x120/0x120 [0.00] [81a83498] x86_64_start_reservations+0x2a/0x2c [0.00] [81a83590] x86_64_start_kernel+0xf6/0xff [0.00] Code: 55 49 89 cd 4c 89 45 d8 e8 db 05 00 00 48 8b 05 2c 6a a2 00 4c 8b 45 d8 44 89 f1 4c 89 e2 48 89 de 48 8b 40 58 4d 89 c1 4d 89 e8 48 8b 78 58 e8 7c 0a 00 00 41 5e 5b 41 5c 41 5d 41 5e 5d c3 55 [0.00] RIP [8103a1db] virt_efi_set_variable+0x40/0x54 [0.00] RSP 81965ee0 [0.00] CR2: fffefde97e70 [0.00] ---[ end trace e9fbc5020b26135e ]--- [0.00] Kernel panic - not syncing: Attempted to kill the idle task! [0.00] Rebooting in 10 seconds.. (-experimental doesn't trigger Fengguang's robot :-)) Good luck! :-) --- From 880fcee20209a122eda846e7f109776ed1c56de5 Mon Sep 17 00:00:00 2001 From: Borislav Petkov b...@suse.de Date: Wed, 18 Sep 2013 17:35:42 +0200 Subject: [PATCH] EFI: Runtime services virtual mapping We map the EFI regions needed for runtime services contiguously on virtual addresses starting from -4G down for a total max space of 64G. This way, we provide for stable runtime services addresses across kernels so that a kexec'd kernel can still use them. This way, they're mapped in a separate pagetable so that we don't pollute the kernel namespace (you can see how the whole ioremapping and saving
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote: I tested your new patch, it works both with efi stub and grub boot in 1st kernel. Good, thanks! But it paniced in kexec boot with my kexec related patcheset, the patchset That's the second kernel, right? contains 3 patch: 1. introduce cmdline kexecboot=0|1|2; 1 == kexec, 2 == kdump 2. export physical addr fw_vendor, runtime, tables to /sys/firmware/efi/systab 3. if kexecboot != 0, use fw_vendor, runtime, tables from bootparams; Also do not call SetVirtualAddressMao in case kexecboot. The panic happens at the last line of efi_init: /* clean DUMMY object */ efi.set_variable(efi_dummy_name, EFI_DUMMY_GUID, EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, 0, NULL); Below is the dmesg: [0.003359] pid_max: default: 32768 minimum: 301 [0.004792] BUG: unable to handle kernel paging request at fffefde97e70 [0.00] IP: [8103a1db] virt_efi_set_variable+0x40/0x54 [0.00] PGD 36981067 PUD 35828063 PMD 0 Here it is - fffefde97e70 is not mapped in the pagetable, PMD is 0. Ok, can you upload your patches somewhere and tell me exactly how to reproduce this so that I can take a look too? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On 09/22/13 at 03:37pm, Borislav Petkov wrote: On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote: I tested your new patch, it works both with efi stub and grub boot in 1st kernel. Good, thanks! But it paniced in kexec boot with my kexec related patcheset, the patchset That's the second kernel, right? Yes, it's 2nd kernel. contains 3 patch: 1. introduce cmdline kexecboot=0|1|2; 1 == kexec, 2 == kdump 2. export physical addr fw_vendor, runtime, tables to /sys/firmware/efi/systab 3. if kexecboot != 0, use fw_vendor, runtime, tables from bootparams; Also do not call SetVirtualAddressMao in case kexecboot. The panic happens at the last line of efi_init: /* clean DUMMY object */ efi.set_variable(efi_dummy_name, EFI_DUMMY_GUID, EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, 0, NULL); Below is the dmesg: [0.003359] pid_max: default: 32768 minimum: 301 [0.004792] BUG: unable to handle kernel paging request at fffefde97e70 [0.00] IP: [8103a1db] virt_efi_set_variable+0x40/0x54 [0.00] PGD 36981067 PUD 35828063 PMD 0 Here it is - fffefde97e70 is not mapped in the pagetable, PMD is 0. Ok, can you upload your patches somewhere and tell me exactly how to reproduce this so that I can take a look too? Ok, will put somewhere after a little cleanup today. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
The address that faults is interesting in that it is indeed just below -4G. The question at hand is probably what information you are using to build the EFI mappings in the secondary kernel and what could make it not match the primary. Assuming it isn't as simple as the mappings never get built at all. Borislav Petkov b...@alien8.de wrote: On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote: I tested your new patch, it works both with efi stub and grub boot in 1st kernel. Good, thanks! But it paniced in kexec boot with my kexec related patcheset, the patchset That's the second kernel, right? contains 3 patch: 1. introduce cmdline kexecboot=0|1|2; 1 == kexec, 2 == kdump 2. export physical addr fw_vendor, runtime, tables to /sys/firmware/efi/systab 3. if kexecboot != 0, use fw_vendor, runtime, tables from bootparams; Also do not call SetVirtualAddressMao in case kexecboot. The panic happens at the last line of efi_init: /* clean DUMMY object */ efi.set_variable(efi_dummy_name, EFI_DUMMY_GUID, EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, 0, NULL); Below is the dmesg: [0.003359] pid_max: default: 32768 minimum: 301 [0.004792] BUG: unable to handle kernel paging request at fffefde97e70 [0.00] IP: [8103a1db] virt_efi_set_variable+0x40/0x54 [0.00] PGD 36981067 PUD 35828063 PMD 0 Here it is - fffefde97e70 is not mapped in the pagetable, PMD is 0. Ok, can you upload your patches somewhere and tell me exactly how to reproduce this so that I can take a look too? Thanks. -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On Sun, Sep 22, 2013 at 08:27:34AM -0700, H. Peter Anvin wrote:a The address that faults is interesting in that it is indeed just below -4G. The question at hand is probably what information you are using to build the EFI mappings in the secondary kernel and what could make it not match the primary. Yep, so obviously we're not building the pagetable in the second kernel the same way as the first or we're missing some pieces. Btw, for debugging situations like this one, one could use arch/x86/mm/dump_pagetables.c successfully by sticking in the right CR3 value into *start. :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -v2] EFI: Runtime services virtual mapping
On Thu, Sep 19, 2013 at 04:54:54PM +0200, Borislav Petkov wrote:
From: Borislav Petkov b...@suse.de
We map the EFI regions needed for runtime services contiguously on
virtual addresses starting from -4G down for a total max space of 64G.
This way, we provide for stable runtime services addresses across
kernels so that a kexec'd kernel can still use them.
This way, they're mapped in a separate pagetable so that we don't
pollute the kernel namespace (you can see how the whole ioremapping and
saving and restoring of PGDs is gone now).
Ok, this one was not so good, let's try again:
This time I saved 32-bit and am switching the pagetable only after
having built it properly. This boots fine again on baremetal and on OVMF
with Matt's handover flags fix from yesterday.
Also, I've uploaded the whole series to
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git, branch
efi-experimental
(-experimental doesn't trigger Fengguang's robot :-))
Good luck! :-)
---
From 880fcee20209a122eda846e7f109776ed1c56de5 Mon Sep 17 00:00:00 2001
From: Borislav Petkov b...@suse.de
Date: Wed, 18 Sep 2013 17:35:42 +0200
Subject: [PATCH] EFI: Runtime services virtual mapping
We map the EFI regions needed for runtime services contiguously on
virtual addresses starting from -4G down for a total max space of 64G.
This way, we provide for stable runtime services addresses across
kernels so that a kexec'd kernel can still use them.
This way, they're mapped in a separate pagetable so that we don't
pollute the kernel namespace (you can see how the whole ioremapping and
saving and restoring of PGDs is gone now).
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/include/asm/efi.h | 43 ++
arch/x86/include/asm/pgtable_types.h | 3 +-
arch/x86/platform/efi/efi.c | 68 -
arch/x86/platform/efi/efi_32.c | 29 +++-
arch/x86/platform/efi/efi_64.c | 85 +++-
arch/x86/platform/efi/efi_stub_64.S | 53 ++
6 files changed, 181 insertions(+), 100 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 0062a0125041..9a99e0499e4b 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -69,24 +69,31 @@ extern u64 efi_call6(void *fp, u64 arg1, u64 arg2, u64 arg3,
efi_call6((f), (u64)(a1), (u64)(a2), (u64)(a3), \
(u64)(a4), (u64)(a5), (u64)(a6))
+#define _efi_call_virtX(x, f, ...) \
+({ \
+ efi_status_t __s; \
+ \
+ efi_sync_low_kernel_mappings(); \
+ preempt_disable(); \
+ __s = efi_call##x((void *)efi.systab-runtime-f, __VA_ARGS__); \
+ preempt_enable(); \
+ __s;\
+})
+
#define efi_call_virt0(f) \
- efi_call0((efi.systab-runtime-f))
-#define efi_call_virt1(f, a1) \
- efi_call1((efi.systab-runtime-f), (u64)(a1))
-#define efi_call_virt2(f, a1, a2) \
- efi_call2((efi.systab-runtime-f), (u64)(a1), (u64)(a2))
-#define efi_call_virt3(f, a1, a2, a3) \
- efi_call3((efi.systab-runtime-f), (u64)(a1), (u64)(a2), \
- (u64)(a3))
-#define efi_call_virt4(f, a1, a2, a3, a4) \
- efi_call4((efi.systab-runtime-f), (u64)(a1), (u64)(a2), \
- (u64)(a3), (u64)(a4))
-#define efi_call_virt5(f, a1, a2, a3, a4, a5) \
- efi_call5((efi.systab-runtime-f), (u64)(a1), (u64)(a2), \
- (u64)(a3), (u64)(a4), (u64)(a5))
-#define efi_call_virt6(f, a1, a2, a3, a4, a5, a6) \
- efi_call6((efi.systab-runtime-f), (u64)(a1), (u64)(a2), \
- (u64)(a3), (u64)(a4), (u64)(a5), (u64)(a6))
+ _efi_call_virtX(0, f)
+#define efi_call_virt1(f, a1) \
+ _efi_call_virtX(1, f, (u64)(a1))
+#define efi_call_virt2(f, a1, a2) \
+ _efi_call_virtX(2, f, (u64)(a1), (u64)(a2))
+#define efi_call_virt3(f, a1, a2, a3) \
+ _efi_call_virtX(3, f, (u64)(a1), (u64)(a2), (u64)(a3))
+#define efi_call_virt4(f, a1, a2, a3, a4) \
+ _efi_call_virtX(4, f, (u64)(a1), (u64)(a2), (u64)(a3), (u64)(a4))
+#define efi_call_virt5(f, a1, a2, a3, a4, a5) \
+ _efi_call_virtX(5, f, (u64)(a1), (u64)(a2), (u64)(a3), (u64)(a4),
(u64)(a5))
+#define efi_call_virt6(f, a1, a2, a3, a4, a5, a6) \
+ _efi_call_virtX(6, f, (u64)(a1),
