x86_64 EFI runtime service support: EFI basic runtime service support

This patch adds basic runtime services support for EFI x86_64 system. The main file of the patch is the addition of efi.c for x86_64. This file is modeled after the EFI IA32 avatar.

EFI runtime
services initialization are implemented in efi.c. Some x86_64 specifics are worth noting here. On x86_64, parameters passed to UEFI firmware services need to follow the UEFI calling convention. For this purpose, a set of functions named lin2win<x> (<x> is the number of parameters) are implemented. EFI function calls are wrapped before calling the firmware service.

+ *
+ * Function calling ABI conversion from SYSV to Windows for x86_64

Quoted 8 lines

EFI runtime
services initialization are implemented in efi.c. Some x86_64 specifics are worth noting here. On x86_64, parameters passed to UEFI firmware services need to follow the UEFI calling convention. For this purpose, a set of functions named lin2win<x> (<x> is the number of parameters) are implemented. EFI function calls are wrapped before calling the firmware service.

Why needs this to be called lin2win? We do not call Windows, we call EFI services, so please use a naming convention which is related to the functionality of the code.

Quoted 3 lines · Ying

This patch adds basic runtime services support for EFI x86_64 system. The main file of the patch is the addition of efi.c for x86_64. This file is modeled after the EFI IA32 avatar.

modeled means copied and modified, right?

This is wrong. I compared efi_32.c and efi_64.c and a large amount of the code is simply the same. The small details can be sorted out by two sets of macros/inline functions easily.

Please fix this up.

I don't think there is a compelling case for us to use any efi services at this time

Quoted 2 lines · On Thu, 25 Oct 2007 10:55:44 -0600 [email protected] (Eric W. Biederman)…

I don't think there is a compelling case for us to use any efi services at this time

I would almost agree with this if it wasn't for the 1 call that OS installers need to tell EFI about bootloader stuff; I've cc'd Peter Jones since he'll know better what OS installers need; if they don't need it after all...

Quoted 10 lines · Arjan van de Ven

Quoted 2 lines · On Thu, 25 Oct 2007 10:55:44 -0600 [email protected] (Eric W. Biederman)…

I don't think there is a compelling case for us to use any efi services at this time

I would almost agree with this if it wasn't for the 1 call that OS installers need to tell EFI about bootloader stuff; I've cc'd Peter Jones since he'll know better what OS installers need; if they don't need it after all...

Yes. I think that is usage of the variable service. Although I don't know if that is actually needed.

Support for the variable service is not implemented in this patchset.

Quoted 2 lines · On Thu, 25 Oct 2007 10:55:44 -0600 [email protected] (Eric W. Biederman)…

I don't think there is a compelling case for us to use any efi services at this time

I would almost agree with this if it wasn't for the 1 call that OS installers need to tell EFI about bootloader stuff; I've cc'd Peter Jones since he'll know better what OS installers need; if they don't need it after all...

Quoted 11 lines · Arjan van de Ven

Quoted 2 lines · On Thu, 25 Oct 2007 10:55:44 -0600 [email protected] (Eric W. Biederman)…

I don't think there is a compelling case for us to use any efi services at this time

I would almost agree with this if it wasn't for the 1 call that OS installers need to tell EFI about bootloader stuff; I've cc'd Peter Jones since he'll know better what OS installers need; if they don't need it after all...

Well, the original motivation for all of this was to enable implementation of a EFI framebuffer (UGA/GOP). Now, you can say what you want about EFI (and I definitely have my opinion on it), but that seems legitimate to me.

Quoted 4 lines

Quoted 1 line

Well, the original motivation for all of this was to enable implementation of a EFI framebuffer (UGA/GOP). Now, you can say what you want about EFI (and I definitely have my opinion on it), but that seems legitimate to me.

To be very clear. I think we need the EFI boot parameters but we certainly don't runtime services to implement an EFI framebuffer.

Quoted 2 lines · Eric W. Biederman

Quoted 2 lines

Quoted 1 line

Well, the original motivation for all of this was to enable implementation of

a

Quoted 6 lines

Quoted 2 lines

EFI framebuffer (UGA/GOP). Now, you can say what you want about EFI (and I definitely have my opinion on it), but that seems legitimate to me.

To be very clear. I think we need the EFI boot parameters but we certainly don't runtime services to implement an EFI framebuffer.

Ying claimed that GOP requires EFI runtime services. Is that not true?

Quoted 2 lines

Quoted 1 line

Ying claimed that GOP requires EFI runtime services. Is that not true?

None of the EFI framebuffer patches that I saw used EFI runtime services.

Quoted 3 lines · Eric W. Biederman

Quoted 2 lines

Quoted 1 line

Ying claimed that GOP requires EFI runtime services. Is that not true?

Quoted 2 lines

None of the EFI framebuffer patches that I saw used EFI runtime services.

Ying, could you please clarify this situation?

(Eric: do note that there are two EFI framebuffer standard, UGA and GOP. Apparently UGA is obsolete and we have always been at war with GOP at the moment.)

Quoted 9 lines · H. Peter Anvin

Quoted 3 lines · Eric W. Biederman

Quoted 1 line

Ying claimed that GOP requires EFI runtime services. Is that not true?

None of the EFI framebuffer patches that I saw used EFI runtime services.

Ying, could you please clarify this situation?

(Eric: do note that there are two EFI framebuffer standard, UGA and GOP. Apparently UGA is obsolete and we have always been at war with GOP at the moment.)

Peter please look back in your email archives to yesterday and see Ying's patch:

[PATCH 1/2 -v2 resend] x86_64 EFI boot support: EFI frame buffer driver

All of the data the GOP needs is acquired through the a query made by the bootloader and passed through screen info.

Quoted 15 lines · Eric W. Biederman

Quoted 9 lines · H. Peter Anvin

Quoted 3 lines · Eric W. Biederman

Quoted 1 line

Ying claimed that GOP requires EFI runtime services. Is that not true?

None of the EFI framebuffer patches that I saw used EFI runtime services.

Ying, could you please clarify this situation?

(Eric: do note that there are two EFI framebuffer standard, UGA and GOP. Apparently UGA is obsolete and we have always been at war with GOP at the moment.)

Peter please look back in your email archives to yesterday and see Ying's patch:

Quoted 5 lines

[PATCH 1/2 -v2 resend] x86_64 EFI boot support: EFI frame buffer driver

All of the data the GOP needs is acquired through the a query made by the bootloader and passed through screen info.

Then I fully agree with your assessment.

Quoted 3 lines · Eric W. Biederman

Quoted 2 lines

Quoted 1 line

Ying claimed that GOP requires EFI runtime services. Is that not true?

Quoted 2 lines

None of the EFI framebuffer patches that I saw used EFI runtime services.

Ying, could you please clarify this situation?

(Eric: do note that there are two EFI framebuffer standard, UGA and GOP.
Apparently UGA is obsolete and we have always been at war with GOP at
the moment.)

Especially for accessing the real time clock that has a well defined hardware interface going through efi an additional software emulation layer looks like asking for trouble.

Quoted 3 lines

Especially for accessing the real time clock that has a well defined hardware interface going through efi an additional software emulation layer looks like asking for trouble.

I agree it's pointless for the hardware clock, but EFI also offers services to write some data to the CMOS RAM which could be very useful to save oops data over reboot.
I don't think this can be done safely otherwise without BIOS cooperation.

Quoted 4 lines · Andi Kleen

Quoted 3 lines

Especially for accessing the real time clock that has a well defined hardware interface going through efi an additional software emulation layer looks like asking for trouble.

Quoted 5 lines

I agree it's pointless for the hardware clock, but EFI also offers services to write some data to the CMOS RAM
which could be very useful to save oops data over reboot.
I don't think this can be done safely otherwise without BIOS cooperation.

The ability to scurry away even a small amount of data without relying on the disk system is highly desirable. Think next-boot type information.

Quoted 5 lines · H. Peter Anvin

Quoted 4 lines · Andi Kleen

Quoted 3 lines

Especially for accessing the real time clock that has a well defined hardware interface going through efi an additional software emulation layer looks like asking for trouble.

Quoted 8 lines

Quoted 5 lines

I agree it's pointless for the hardware clock, but EFI also offers services to write some data to the CMOS RAM
which could be very useful to save oops data over reboot.
I don't think this can be done safely otherwise without BIOS cooperation.

The ability to scurry away even a small amount of data without relying on the disk system is highly desirable. Think next-boot type information.

Yes. If that were to be the justifying case and if that was what the code was implementing I could see the point.

However this point was made in an earlier review. This point was already been made, and still this patchset doesn't include that functionality and it still includes the code to disable direct hardware access for no seemingly sane reason.

Quoted 7 lines

EFI runtime
services initialization are implemented in efi.c. Some x86_64 specifics are worth noting here. On x86_64, parameters passed to UEFI firmware services need to follow the UEFI calling convention. For this purpose, a set of functions named lin2win<x> (<x> is the number of parameters) are implemented. EFI function calls are wrapped before calling the firmware service.

Why needs this to be called lin2win? We do not call Windows, we call EFI services, so please use a naming convention which is related to the functionality of the code.

Quoted 2 lines

+ *
+ * Function calling ABI conversion from SYSV to Windows for x86_64

Again, these are wrappers to access EFI and not Windows.

Quoted 12 lines · Thomas Gleixner

Quoted 7 lines

EFI runtime
services initialization are implemented in efi.c. Some x86_64 specifics are worth noting here. On x86_64, parameters passed to UEFI firmware services need to follow the UEFI calling convention. For this purpose, a set of functions named lin2win<x> (<x> is the number of parameters) are implemented. EFI function calls are wrapped before calling the firmware service.

Why needs this to be called lin2win? We do not call Windows, we call EFI services, so please use a naming convention which is related to the functionality of the code.

Quoted 4 lines

Quoted 2 lines

+ *
+ * Function calling ABI conversion from SYSV to Windows for x86_64

Again, these are wrappers to access EFI and not Windows.

EFI uses the Windows x86_64 calling convention. The lin2win may be a more general naming convention that can be used for some other code (the NDISwrapper?) in the future. Do you agree?

Quoted 3 lines

EFI uses the Windows x86_64 calling convention. The lin2win may be a more general naming convention that can be used for some other code (the NDISwrapper?) in the future. Do you agree?

I agree not at all. I do not care whether the EFI creators smoked the Windows-crackpipe or some other hallucinogen when they decided to use this calling convention. We definitely do not want to think about NDISwrapper or any other Windows related hackery in the kernel.

I still do not understand why we need all this EFI hackery at all aside of the possible usage for saving a crash dump on FLASH, which we could do directly from the kernel as well.

Quoted 8 lines · Thomas Gleixner

Quoted 3 lines

EFI uses the Windows x86_64 calling convention. The lin2win may be a more general naming convention that can be used for some other code (the NDISwrapper?) in the future. Do you agree?

I agree not at all. I do not care whether the EFI creators smoked the Windows-crackpipe or some other hallucinogen when they decided to use this calling convention. We definitely do not want to think about NDISwrapper or any other Windows related hackery in the kernel.

OK, I will change the name to something like lin2efi.

I still do not understand why we need all this EFI hackery at all aside of the possible usage for saving a crash dump on FLASH, which we could do directly from the kernel as well.

Quoted 12 lines · Thomas Gleixner

Quoted 7 lines

EFI runtime
services initialization are implemented in efi.c. Some x86_64 specifics are worth noting here. On x86_64, parameters passed to UEFI firmware services need to follow the UEFI calling convention. For this purpose, a set of functions named lin2win<x> (<x> is the number of parameters) are implemented. EFI function calls are wrapped before calling the firmware service.

Why needs this to be called lin2win? We do not call Windows, we call EFI services, so please use a naming convention which is related to the functionality of the code.

Quoted 4 lines

Quoted 2 lines

+ *
+ * Function calling ABI conversion from SYSV to Windows for x86_64

Again, these are wrappers to access EFI and not Windows.

EFI uses the Windows x86_64 calling convention. The lin2win may be a more general naming convention that can be used for some other code (the NDISwrapper?) in the future. Do you agree?

Quoted 4 lines

Quoted 1 line

Again, these are wrappers to access EFI and not Windows.

EFI uses the Windows x86_64 calling convention. The lin2win may be a more general naming convention that can be used for some other code (the NDISwrapper?) in the future. Do you agree?

The SYSV description is wrong as well. SYSV has no calling convention. I think you mean iABI or iBCS2 ?

Whats wrong with following the pattern of other calls like syscall(...) and just having eficall() ?

Quoted 16 lines · Ying

Quoted 15 lines · Thomas Gleixner

Quoted 7 lines

EFI runtime
services initialization are implemented in efi.c. Some x86_64 specifics are worth noting here. On x86_64, parameters passed to UEFI firmware services need to follow the UEFI calling convention. For this purpose, a set of functions named lin2win<x> (<x> is the number of parameters) are implemented. EFI function calls are wrapped before calling the firmware service.

Why needs this to be called lin2win? We do not call Windows, we call EFI services, so please use a naming convention which is related to the functionality of the code.

Quoted 2 lines

+ *
+ * Function calling ABI conversion from SYSV to Windows for x86_64

Quoted 5 lines

Quoted 1 line

Again, these are wrappers to access EFI and not Windows.

EFI uses the Windows x86_64 calling convention. The lin2win may be a more general naming convention that can be used for some other code (the NDISwrapper?) in the future. Do you agree?

The SYSV description is wrong as well. SYSV has no calling convention. I think you mean iABI or iBCS2 ?

Whats wrong with following the pattern of other calls like syscall(...) and just having eficall() ?

Quoted 3 lines · Ying

This patch adds basic runtime services support for EFI x86_64 system. The main file of the patch is the addition of efi.c for x86_64. This file is modeled after the EFI IA32 avatar.

modeled means copied and modified, right?

This is wrong. I compared efi_32.c and efi_64.c and a large amount of the code is simply the same. The small details can be sorted out by two sets of macros/inline functions easily.

Please fix this up.

- 3 files: efi.c, efi_32.c, efi_64.c, common code goes in efi.c, EFI 32/64 specific code goes in efi_32/64.c. This will make some variable, function external instead of static.

arch/x86/kernel/efi_64.c new file +34 -0

+static void __init efi_call_phys_prelog(void) __acquires(efi_lock)
+{
+	unsigned long vaddress;
+
+	/*
+	 * Lock sequence is different from normal case because
+	 * efi_flags is global
+	 */
+	spin_lock(&efi_lock);
+	local_irq_save(efi_flags);
+	early_runtime_code_mapping_set_exec(1);
+	vaddress = (unsigned long)__va(0x0UL);
+	pgd_val(save_pgd) = pgd_val(*pgd_offset_k(0x0UL));
+	set_pgd(pgd_offset_k(0x0UL), *pgd_offset_k(vaddress));
+	global_flush_tlb();
+}
+
+static void __init efi_call_phys_epilog(void) __releases(efi_lock)
+{
+	/*
+	 * After the lock is released, the original page table is restored.
+	 */
+	set_pgd(pgd_offset_k(0x0UL), save_pgd);
+	early_runtime_code_mapping_set_exec(0);
+	global_flush_tlb();
+	local_irq_restore(efi_flags);
+	spin_unlock(&efi_lock);
+}
+
+static efi_status_t __init phys_efi_set_virtual_address_map(
+	unsigned long memory_map_size,
+	unsigned long descriptor_size,
+	u32 descriptor_version,
+	efi_memory_desc_t *virtual_map)

Quoted 14 lines

arch/x86/kernel/efi_64.c new file +14 -0

+static efi_status_t __init phys_efi_set_virtual_address_map(
+	unsigned long memory_map_size,
+	unsigned long descriptor_size,
+	u32 descriptor_version,
+	efi_memory_desc_t *virtual_map)
+{
+	efi_status_t status;
+
+	efi_call_phys_prelog();
+	status = lin2win4((void *)efi_phys.set_virtual_address_map,
+			  (u64)memory_map_size, (u64)descriptor_size,
+			  (u64)descriptor_version, (u64)virtual_map);
+	efi_call_phys_epilog();
+	return status;

Quoted 1 line

+}

So you still have this piece of code which makes a kernel using efi not compatible with kexec. But you are still supporting a physical call mode for efi. If you are going to do this can we please just remove the hacks that make the EFI physical call mode early boot only and just always use that mode. Depending on weird call once functions like efi_set_virtual_address_map makes me very uncomfortable.