Re: [PATCH 3/4] arm: Add [U]EFI runtime services support

2013-06-26 Thread Grant Likely
On Tue, Jun 25, 2013 at 7:11 PM, Leif Lindholm leif.lindh...@linaro.org wrote:
 This patch implements basic support for UEFI runtime services in the
 ARM architecture - a requirement for using efibootmgr to read and update
 the system boot configuration.

 It also locates any presented SMBIOS configuration table and stores it
 for potential later use by DMI.

 Signed-off-by: Leif Lindholm leif.lindh...@linaro.org
 ---
  arch/arm/Kconfig   |   15 ++
  arch/arm/include/asm/efi.h |   22 +++
  arch/arm/kernel/Makefile   |2 +
  arch/arm/kernel/efi.c  |  456 
 
  arch/arm/kernel/efi_phys.S |   59 ++
  arch/arm/kernel/setup.c|5 +
  6 files changed, 559 insertions(+)
  create mode 100644 arch/arm/include/asm/efi.h
  create mode 100644 arch/arm/kernel/efi.c
  create mode 100644 arch/arm/kernel/efi_phys.S

 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index bf8e55d..022d2eb 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -1763,6 +1763,19 @@ config EARLY_IOREMAP
   Provides a mechanism for kernel initialisation code to temporarily
   map, in a highmem-agnostic way, memory pages in before 
 paging_init().

 +config EFI
 +bool UEFI runtime service support
 +   depends on OF
 +   select UCS2_STRING
 +   select EARLY_IOREMAP
 +   ---help---
 + This enables the kernel to use UEFI runtime services that are
 + available (such as the UEFI variable services).
 +
 + This option is only useful on systems that have UEFI firmware.
 + However, even with this option, the resultant kernel should

Be confident!  s/should/will/  :-)

 + continue to boot on existing non-UEFI platforms.

s/existing//

 +
  config SECCOMP
 bool
 prompt Enable seccomp to safely compute untrusted bytecode
 @@ -2217,6 +2230,8 @@ source net/Kconfig

  source drivers/Kconfig

 +source drivers/firmware/Kconfig
 +
  source fs/Kconfig

  source arch/arm/Kconfig.debug
 diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
 new file mode 100644
 index 000..aead94c
 --- /dev/null
 +++ b/arch/arm/include/asm/efi.h
 @@ -0,0 +1,22 @@
 +#ifndef _ASM_ARM_EFI_H
 +#define _ASM_ARM_EFI_H
 +
 +#include asm/mach/map.h
 +
 +extern int efi_memblock_arm_reserve_range(void);
 +
 +typedef efi_status_t efi_phys_call_t(u32 memory_map_size,
 +u32 descriptor_size,
 +u32 descriptor_version,
 +efi_memory_desc_t *dsc,
 +efi_set_virtual_address_map_t *f);
 +
 +extern efi_status_t efi_phys_call(u32, u32, u32, efi_memory_desc_t *,
 + efi_set_virtual_address_map_t *);
 +
 +#define efi_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY)
 +#define efi_ioremap(cookie, size) __arm_ioremap((cookie), (size), MT_DEVICE)
 +#define efi_unmap(cookie) __arm_iounmap((cookie))
 +#define efi_iounmap(cookie) __arm_iounmap((cookie))
 +
 +#endif /* _ASM_ARM_EFI_H */
 diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
 index 5f3338e..12b9c30 100644
 --- a/arch/arm/kernel/Makefile
 +++ b/arch/arm/kernel/Makefile
 @@ -84,4 +84,6 @@ obj-$(CONFIG_EARLY_PRINTK)+= early_printk.o
  obj-$(CONFIG_ARM_VIRT_EXT) += hyp-stub.o
  obj-$(CONFIG_ARM_PSCI) += psci.o

 +obj-$(CONFIG_EFI)  += efi.o efi_phys.o
 +
  extra-y := $(head-y) vmlinux.lds
 diff --git a/arch/arm/kernel/efi.c b/arch/arm/kernel/efi.c
 new file mode 100644
 index 000..43ecf0b
 --- /dev/null
 +++ b/arch/arm/kernel/efi.c
 @@ -0,0 +1,456 @@
 +/*
 + * Extensible Firmware Interface
 + *
 + * Based on Extensible Firmware Interface Specification version 2.3.1
 + *
 + * Copyright (C) 2013 Linaro Ltd.

Was any of the above code extracted from the x86/ia64 efi code base?
If so then make sure the copyright header and license text gets
retained.

 + *
 + */
 +
 +#include linux/efi.h
 +#include linux/export.h
 +#include linux/memblock.h
 +#include linux/of.h
 +#include linux/of_fdt.h
 +#include linux/sched.h
 +#include linux/slab.h
 +
 +#include asm/cacheflush.h
 +#include asm/efi.h
 +#include asm/idmap.h
 +#include asm/tlbflush.h
 +
 +struct efi efi;
 +EXPORT_SYMBOL(efi);
 +struct efi_memory_map memmap;

The above symbols should be pulled out of x86 and ia64 and made part
of drivers/efi/efi.c. Although in my quick look I don't see memmap
defined for ia64. You'll need to make sure that it actually exists
before moving it. That will also affect your earlier patch which moves
the memmap lookup function. I suspect that function won't build on
ia64.

 +
 +static efi_runtime_services_t *runtime;
 +
 +static phys_addr_t efi_system_table;
 +static phys_addr_t efi_boot_mmap;
 +static u32 efi_boot_mmap_size;
 +static u32 efi_mmap_desc_size;
 +static u32 efi_mmap_desc_ver;
 +
 +/* Default memory map descriptor information */
 +#define DESC_SIZE 48
 +#define 

Re: [PATCH 3/4] arm: Add [U]EFI runtime services support

2013-06-26 Thread Grant Likely
On Tue, Jun 25, 2013 at 7:20 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
 On Tue, Jun 25, 2013 at 07:11:02PM +0100, Leif Lindholm wrote:
 This patch implements basic support for UEFI runtime services in the
 ARM architecture - a requirement for using efibootmgr to read and update
 the system boot configuration.

 It also locates any presented SMBIOS configuration table and stores it
 for potential later use by DMI.

 This appears to duplicate code that's already duplicated between x86 and
 ia64. We made a mistake there originally - let's not do it again. Having
 this code in three places is inevitably going to lead to skew and missed
 bugfixes.

+1


 --
 Matthew Garrett | mj...@srcf.ucam.org
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
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 3/4] arm: Add [U]EFI runtime services support

2013-06-26 Thread Borislav Petkov
On Wed, Jun 26, 2013 at 02:54:17PM +0100, Matt Fleming wrote:
 On Wed, 26 Jun, at 02:46:09PM, Grant Likely wrote:
  Eventually we'll need to look at how this interacts with kexec. A
  kexec'd kernel will need to use the mapping already chosen by a
  previous kernel, but that's an issue for another patch series.
 
 FYI, this is exactly what Borislav has been tackling on x86 recently. It
 would be nice if we could find one scheme that suits everyone.

Is this arm 32 or 64-bit? Because we haven't talked about 32-bit on x86
either. From skimming over the code, I'm not sure the same top-down
allocation and 1:1 mapping would work there. But I haven't looked hard
yet so I dunno.

-- 
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 3/4] arm: Add [U]EFI runtime services support

2013-06-26 Thread Leif Lindholm
On Wed, Jun 26, 2013 at 02:46:09PM +0100, Grant Likely wrote:
  This patch implements basic support for UEFI runtime services in the
  ARM architecture - a requirement for using efibootmgr to read and update
  the system boot configuration.
 
  It also locates any presented SMBIOS configuration table and stores it
  for potential later use by DMI.
 
  Signed-off-by: Leif Lindholm leif.lindh...@linaro.org
  ---
   arch/arm/Kconfig   |   15 ++
   arch/arm/include/asm/efi.h |   22 +++
   arch/arm/kernel/Makefile   |2 +
   arch/arm/kernel/efi.c  |  456 
  
   arch/arm/kernel/efi_phys.S |   59 ++
   arch/arm/kernel/setup.c|5 +
   6 files changed, 559 insertions(+)
   create mode 100644 arch/arm/include/asm/efi.h
   create mode 100644 arch/arm/kernel/efi.c
   create mode 100644 arch/arm/kernel/efi_phys.S
 
  diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
  index bf8e55d..022d2eb 100644
  --- a/arch/arm/Kconfig
  +++ b/arch/arm/Kconfig
  @@ -1763,6 +1763,19 @@ config EARLY_IOREMAP
Provides a mechanism for kernel initialisation code to temporarily
map, in a highmem-agnostic way, memory pages in before 
  paging_init().
 
  +config EFI
  +bool UEFI runtime service support
  +   depends on OF
  +   select UCS2_STRING
  +   select EARLY_IOREMAP
  +   ---help---
  + This enables the kernel to use UEFI runtime services that are
  + available (such as the UEFI variable services).
  +
  + This option is only useful on systems that have UEFI firmware.
  + However, even with this option, the resultant kernel should
 
 Be confident!  s/should/will/  :-)
 
Ok.

  + continue to boot on existing non-UEFI platforms.
 
 s/existing//
 
Ok.

  +
   config SECCOMP
  bool
  prompt Enable seccomp to safely compute untrusted bytecode
  @@ -2217,6 +2230,8 @@ source net/Kconfig
 
   source drivers/Kconfig
 
  +source drivers/firmware/Kconfig
  +
   source fs/Kconfig
 
   source arch/arm/Kconfig.debug
  diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
  new file mode 100644
  index 000..aead94c
  --- /dev/null
  +++ b/arch/arm/include/asm/efi.h
  @@ -0,0 +1,22 @@
  +#ifndef _ASM_ARM_EFI_H
  +#define _ASM_ARM_EFI_H
  +
  +#include asm/mach/map.h
  +
  +extern int efi_memblock_arm_reserve_range(void);
  +
  +typedef efi_status_t efi_phys_call_t(u32 memory_map_size,
  +u32 descriptor_size,
  +u32 descriptor_version,
  +efi_memory_desc_t *dsc,
  +efi_set_virtual_address_map_t *f);
  +
  +extern efi_status_t efi_phys_call(u32, u32, u32, efi_memory_desc_t *,
  + efi_set_virtual_address_map_t *);
  +
  +#define efi_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY)
  +#define efi_ioremap(cookie, size) __arm_ioremap((cookie), (size), 
  MT_DEVICE)
  +#define efi_unmap(cookie) __arm_iounmap((cookie))
  +#define efi_iounmap(cookie) __arm_iounmap((cookie))
  +
  +#endif /* _ASM_ARM_EFI_H */
  diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
  index 5f3338e..12b9c30 100644
  --- a/arch/arm/kernel/Makefile
  +++ b/arch/arm/kernel/Makefile
  @@ -84,4 +84,6 @@ obj-$(CONFIG_EARLY_PRINTK)+= early_printk.o
   obj-$(CONFIG_ARM_VIRT_EXT) += hyp-stub.o
   obj-$(CONFIG_ARM_PSCI) += psci.o
 
  +obj-$(CONFIG_EFI)  += efi.o efi_phys.o
  +
   extra-y := $(head-y) vmlinux.lds
  diff --git a/arch/arm/kernel/efi.c b/arch/arm/kernel/efi.c
  new file mode 100644
  index 000..43ecf0b
  --- /dev/null
  +++ b/arch/arm/kernel/efi.c
  @@ -0,0 +1,456 @@
  +/*
  + * Extensible Firmware Interface
  + *
  + * Based on Extensible Firmware Interface Specification version 2.3.1
  + *
  + * Copyright (C) 2013 Linaro Ltd.
 
 Was any of the above code extracted from the x86/ia64 efi code base?
 If so then make sure the copyright header and license text gets
 retained.
 
Well, some of efi_config_init() was, but it looks like I will be movng
it out now.

  + *
  + */
  +
  +#include linux/efi.h
  +#include linux/export.h
  +#include linux/memblock.h
  +#include linux/of.h
  +#include linux/of_fdt.h
  +#include linux/sched.h
  +#include linux/slab.h
  +
  +#include asm/cacheflush.h
  +#include asm/efi.h
  +#include asm/idmap.h
  +#include asm/tlbflush.h
  +
  +struct efi efi;
  +EXPORT_SYMBOL(efi);
  +struct efi_memory_map memmap;
 
 The above symbols should be pulled out of x86 and ia64 and made part
 of drivers/efi/efi.c. Although in my quick look I don't see memmap
 defined for ia64. You'll need to make sure that it actually exists
 before moving it.

Happy to do that. Can be ifdef'd if need be.

 That will also affect your earlier patch which moves
 the memmap lookup function. I suspect that function won't build on
 ia64.

Argh, indeed. I had that ifdef'd 

Re: [PATCH 3/4] arm: Add [U]EFI runtime services support

2013-06-26 Thread Grant Likely
On Wed, Jun 26, 2013 at 3:15 PM, Borislav Petkov b...@alien8.de wrote:
 On Wed, Jun 26, 2013 at 02:54:17PM +0100, Matt Fleming wrote:
 On Wed, 26 Jun, at 02:46:09PM, Grant Likely wrote:
  Eventually we'll need to look at how this interacts with kexec. A
  kexec'd kernel will need to use the mapping already chosen by a
  previous kernel, but that's an issue for another patch series.

 FYI, this is exactly what Borislav has been tackling on x86 recently. It
 would be nice if we could find one scheme that suits everyone.

 Is this arm 32 or 64-bit? Because we haven't talked about 32-bit on x86
 either. From skimming over the code, I'm not sure the same top-down
 allocation and 1:1 mapping would work there. But I haven't looked hard
 yet so I dunno.

This is arm 32. We'll be looking at arm 64 next.

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