Re: [PATCH v6 1/9] efi: Use early_mem*() instead of early_io*()

2014-06-23 Thread Jan Beulich 
 On 20.06.14 at 23:29, daniel.ki...@oracle.com wrote:
 --- a/drivers/firmware/efi/efi.c
 +++ b/drivers/firmware/efi/efi.c
 @@ -298,7 +298,7 @@ int __init efi_config_init(efi_config_table_type_t 
 *arch_tables)
   if (table64  32) {
   pr_cont(\n);
   pr_err(Table located above 4GB, disabling 
 EFI.\n);
 - early_iounmap(config_tables,
 + early_memunmap(config_tables,
  efi.systab-nr_tables * sz);
   return -EINVAL;
   }
 @@ -314,7 +314,7 @@ int __init efi_config_init(efi_config_table_type_t 
 *arch_tables)
   tablep += sz;
   }
   pr_cont(\n);
 - early_iounmap(config_tables, efi.systab-nr_tables * sz);
 + early_memunmap(config_tables, efi.systab-nr_tables * sz);
  
   set_bit(EFI_CONFIG_TABLES, efi.flags);
  

If these two changes are really deemed necessary (there's the
implied assumption currently in place that early_iounmap() can
undo early_memremap() mappings), then ia64 will need a
definition added for early_memunmap() or its build will break.

Jan

--
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 v6 6/9] xen: Define EFI related stuff

2014-06-23 Thread David Vrabel 
On 20/06/14 22:29, Daniel Kiper wrote:
 Define constants and structures which are needed to properly
 execute EFI related hypercall in Xen dom0.

Reviewed-by: David Vrabel david.vra...@citrix.com

Thanks.

David
--
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 v6 2/9] arch/x86: Do not access EFI memory map if it is not available

2014-06-23 Thread David Vrabel 
On 20/06/14 22:29, Daniel Kiper wrote:
 Do not access EFI memory map if it is not available. At least
 Xen dom0 EFI implementation does not have an access to it.

Could it make one based on the XENMEM_memory_map or
XENMEM_machine_memory_map hypercall?

David
--
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: [Xen-devel] [PATCH v6 7/9] xen: Put EFI machinery in place

2014-06-23 Thread David Vrabel 
On 20/06/14 22:29, Daniel Kiper wrote:
 This patch enables EFI usage under Xen dom0. Standard EFI Linux
 Kernel infrastructure cannot be used because it requires direct
 access to EFI data and code. However, in dom0 case it is not possible
 because above mentioned EFI stuff is fully owned and controlled
 by Xen hypervisor. In this case all calls from dom0 to EFI must
 be requested via special hypercall which in turn executes relevant
 EFI code in behalf of dom0.
 
 When dom0 kernel boots it checks for EFI availability on a machine.
 If it is detected then artificial EFI system table is filled.
 Native EFI callas are replaced by functions which mimics them
 by calling relevant hypercall. Later pointer to EFI system table
 is passed to standard EFI machinery and it continues EFI subsystem
 initialization taking into account that there is no direct access
 to EFI boot services, runtime, tables, structures, etc. After that
 system runs as usual.

Reviewed-by: David Vrabel david.vra...@citrix.com

(With or without the change suggested by Stefano).

Thanks.

David
--
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 v6 2/9] arch/x86: Do not access EFI memory map if it is not available

2014-06-23 Thread Jan Beulich 
 On 23.06.14 at 11:53, david.vra...@citrix.com wrote:
 On 20/06/14 22:29, Daniel Kiper wrote:
 Do not access EFI memory map if it is not available. At least
 Xen dom0 EFI implementation does not have an access to it.
 
 Could it make one based on the XENMEM_memory_map or
 XENMEM_machine_memory_map hypercall?

No, the correct operation to implement this and efi_mem_type()
similar function is XEN_FW_EFI_INFO, index XEN_FW_EFI_MEM_INFO.

Jan

--
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 v6 1/9] efi: Use early_mem*() instead of early_io*()

2014-06-23 Thread Daniel Kiper 
I am CC'ing IA-64 guys.

On Mon, Jun 23, 2014 at 08:19:00AM +0100, Jan Beulich wrote:
  On 20.06.14 at 23:29, daniel.ki...@oracle.com wrote:
  --- a/drivers/firmware/efi/efi.c
  +++ b/drivers/firmware/efi/efi.c
  @@ -298,7 +298,7 @@ int __init efi_config_init(efi_config_table_type_t 
  *arch_tables)
  if (table64  32) {
  pr_cont(\n);
  pr_err(Table located above 4GB, disabling 
  EFI.\n);
  -   early_iounmap(config_tables,
  +   early_memunmap(config_tables,
 efi.systab-nr_tables * sz);
  return -EINVAL;
  }
  @@ -314,7 +314,7 @@ int __init efi_config_init(efi_config_table_type_t 
  *arch_tables)
  tablep += sz;
  }
  pr_cont(\n);
  -   early_iounmap(config_tables, efi.systab-nr_tables * sz);
  +   early_memunmap(config_tables, efi.systab-nr_tables * sz);
 
  set_bit(EFI_CONFIG_TABLES, efi.flags);
 

 If these two changes are really deemed necessary (there's the
 implied assumption currently in place that early_iounmap() can
 undo early_memremap() mappings), then ia64 will need a
 definition added for early_memunmap() or its build will break.

I know that early_memunmap() == early_iounmap() in general. However,
I think that it is less confusing if use relevant functions in pairs
(i.e. early_memremap() with early_memunmap(), ...) than mix them up.

We have following choices here:
  - leave early_iounmap() as is in drivers/firmware/efi/efi.c
(arch/x86/platform/efi/efi.c:early_iounmap() - early_memunmap()
changes should be left as is),
  - include asm/early_ioremap.h in arch/ia64/include/asm/io.h
(as I can see the same think is done for x86 and arm64).

I prefer second solution but I do not insist.

Daniel
--
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: [Xen-devel] [PATCH v6 7/9] xen: Put EFI machinery in place

2014-06-23 Thread Daniel Kiper 
On Mon, Jun 23, 2014 at 10:57:31AM +0100, David Vrabel wrote:
 On 20/06/14 22:29, Daniel Kiper wrote:
  This patch enables EFI usage under Xen dom0. Standard EFI Linux
  Kernel infrastructure cannot be used because it requires direct
  access to EFI data and code. However, in dom0 case it is not possible
  because above mentioned EFI stuff is fully owned and controlled
  by Xen hypervisor. In this case all calls from dom0 to EFI must
  be requested via special hypercall which in turn executes relevant
  EFI code in behalf of dom0.
 
  When dom0 kernel boots it checks for EFI availability on a machine.
  If it is detected then artificial EFI system table is filled.
  Native EFI callas are replaced by functions which mimics them
  by calling relevant hypercall. Later pointer to EFI system table
  is passed to standard EFI machinery and it continues EFI subsystem
  initialization taking into account that there is no direct access
  to EFI boot services, runtime, tables, structures, etc. After that
  system runs as usual.

 Reviewed-by: David Vrabel david.vra...@citrix.com

Thanks for this and second one.

 (With or without the change suggested by Stefano).

I am going to take into account Stefano's idea.

Daniel
--
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 v6 2/9] arch/x86: Do not access EFI memory map if it is not available

2014-06-23 Thread Daniel Kiper 
On Mon, Jun 23, 2014 at 12:00:01PM +0100, Jan Beulich wrote:
  On 23.06.14 at 11:53, david.vra...@citrix.com wrote:
  On 20/06/14 22:29, Daniel Kiper wrote:
  Do not access EFI memory map if it is not available. At least
  Xen dom0 EFI implementation does not have an access to it.
 
  Could it make one based on the XENMEM_memory_map or
  XENMEM_machine_memory_map hypercall?

 No, the correct operation to implement this and efi_mem_type()
 similar function is XEN_FW_EFI_INFO, index XEN_FW_EFI_MEM_INFO.

efi_mem_attributes() is used only on IA-64 arch. So, that is why
I completely removed relevant Xen code.

Daniel
--
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 1/2] efi/x86: move UEFI Runtime Services wrappers to generic code

2014-06-23 Thread Ard Biesheuvel 
In order for other archs (such as arm64) to be able to reuse the virtual mode
function call wrappers, move them to drivers/firmware/efi/runtime.c.

Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 arch/x86/platform/efi/efi.c| 144 +--
 drivers/firmware/efi/Makefile  |   2 +-
 drivers/firmware/efi/runtime.c | 167 +
 include/linux/efi.h|   2 +
 4 files changed, 172 insertions(+), 143 deletions(-)
 create mode 100644 drivers/firmware/efi/runtime.c

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 87fc96bcc13c..36d0835210c3 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -104,130 +104,6 @@ static int __init setup_storage_paranoia(char *arg)
 }
 early_param(efi_no_storage_paranoia, setup_storage_paranoia);
 
-static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
-{
-   unsigned long flags;
-   efi_status_t status;
-
-   spin_lock_irqsave(rtc_lock, flags);
-   status = efi_call_virt(get_time, tm, tc);
-   spin_unlock_irqrestore(rtc_lock, flags);
-   return status;
-}
-
-static efi_status_t virt_efi_set_time(efi_time_t *tm)
-{
-   unsigned long flags;
-   efi_status_t status;
-
-   spin_lock_irqsave(rtc_lock, flags);
-   status = efi_call_virt(set_time, tm);
-   spin_unlock_irqrestore(rtc_lock, flags);
-   return status;
-}
-
-static efi_status_t virt_efi_get_wakeup_time(efi_bool_t *enabled,
-efi_bool_t *pending,
-efi_time_t *tm)
-{
-   unsigned long flags;
-   efi_status_t status;
-
-   spin_lock_irqsave(rtc_lock, flags);
-   status = efi_call_virt(get_wakeup_time, enabled, pending, tm);
-   spin_unlock_irqrestore(rtc_lock, flags);
-   return status;
-}
-
-static efi_status_t virt_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t 
*tm)
-{
-   unsigned long flags;
-   efi_status_t status;
-
-   spin_lock_irqsave(rtc_lock, flags);
-   status = efi_call_virt(set_wakeup_time, enabled, tm);
-   spin_unlock_irqrestore(rtc_lock, flags);
-   return status;
-}
-
-static efi_status_t virt_efi_get_variable(efi_char16_t *name,
- efi_guid_t *vendor,
- u32 *attr,
- unsigned long *data_size,
- void *data)
-{
-   return efi_call_virt(get_variable,
-name, vendor, attr,
-data_size, data);
-}
-
-static efi_status_t virt_efi_get_next_variable(unsigned long *name_size,
-  efi_char16_t *name,
-  efi_guid_t *vendor)
-{
-   return efi_call_virt(get_next_variable,
-name_size, name, vendor);
-}
-
-static efi_status_t virt_efi_set_variable(efi_char16_t *name,
- efi_guid_t *vendor,
- u32 attr,
- unsigned long data_size,
- void *data)
-{
-   return efi_call_virt(set_variable,
-name, vendor, attr,
-data_size, data);
-}
-
-static efi_status_t virt_efi_query_variable_info(u32 attr,
-u64 *storage_space,
-u64 *remaining_space,
-u64 *max_variable_size)
-{
-   if (efi.runtime_version  EFI_2_00_SYSTEM_TABLE_REVISION)
-   return EFI_UNSUPPORTED;
-
-   return efi_call_virt(query_variable_info, attr, storage_space,
-remaining_space, max_variable_size);
-}
-
-static efi_status_t virt_efi_get_next_high_mono_count(u32 *count)
-{
-   return efi_call_virt(get_next_high_mono_count, count);
-}
-
-static void virt_efi_reset_system(int reset_type,
- efi_status_t status,
- unsigned long data_size,
- efi_char16_t *data)
-{
-   __efi_call_virt(reset_system, reset_type, status,
-   data_size, data);
-}
-
-static efi_status_t virt_efi_update_capsule(efi_capsule_header_t **capsules,
-   unsigned long count,
-   unsigned long sg_list)
-{
-   if (efi.runtime_version  EFI_2_00_SYSTEM_TABLE_REVISION)
-   return EFI_UNSUPPORTED;
-
-   return efi_call_virt(update_capsule, capsules, count, sg_list);
-}
-
-static efi_status_t virt_efi_query_capsule_caps(efi_capsule_header_t 
**capsules,
-   unsigned long count,
-

[PATCH 2/2] efi/arm64: preserve NEON registers on UEFI runtime services calls

2014-06-23 Thread Ard Biesheuvel 
UEFI Runtime Services function calls may clobber the contents of the NEON
register file, so we need to make sure that we preserve/restore them when
performing such a function call.

Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 arch/arm64/include/asm/efi.h | 21 +
 arch/arm64/kernel/efi.c  | 14 +-
 2 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 5a46c4e7f539..375ba342dca6 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -2,6 +2,7 @@
 #define _ASM_EFI_H
 
 #include asm/io.h
+#include asm/neon.h
 
 #ifdef CONFIG_EFI
 extern void efi_init(void);
@@ -11,4 +12,24 @@ extern void efi_idmap_init(void);
 #define efi_idmap_init()
 #endif
 
+#define efi_call_virt(f, ...)  \
+({ \
+   efi_##f##_t *__f = efi.systab-runtime-f;  \
+   efi_status_t __s;   \
+   \
+   kernel_neon_begin();\
+   __s = __f(__VA_ARGS__); \
+   kernel_neon_end();  \
+   __s;\
+})
+
+#define __efi_call_virt(f, ...)
\
+({ \
+   efi_##f##_t *__f = efi.systab-runtime-f;  \
+   \
+   kernel_neon_begin();\
+   __f(__VA_ARGS__);   \
+   kernel_neon_end();  \
+})
+
 #endif /* _ASM_EFI_H */
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 14db1f6e8d7f..56c3327bbf79 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -449,19 +449,7 @@ static int __init arm64_enter_virtual_mode(void)
 
/* Set up runtime services function pointers */
runtime = efi.systab-runtime;
-   efi.get_time = runtime-get_time;
-   efi.set_time = runtime-set_time;
-   efi.get_wakeup_time = runtime-get_wakeup_time;
-   efi.set_wakeup_time = runtime-set_wakeup_time;
-   efi.get_variable = runtime-get_variable;
-   efi.get_next_variable = runtime-get_next_variable;
-   efi.set_variable = runtime-set_variable;
-   efi.query_variable_info = runtime-query_variable_info;
-   efi.update_capsule = runtime-update_capsule;
-   efi.query_capsule_caps = runtime-query_capsule_caps;
-   efi.get_next_high_mono_count = runtime-get_next_high_mono_count;
-   efi.reset_system = runtime-reset_system;
-
+   efi_native_runtime_setup();
set_bit(EFI_RUNTIME_SERVICES, efi.flags);
 
return 0;
-- 
1.8.3.2

--
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 0/2] efi: preserve NEON registers on UEFI services calls

2014-06-23 Thread Ard Biesheuvel 
The current UEFI implementation for arm64 fails to preserve/restore the contents
of the NEON register file, which may result in data corruption, especially now
that those contents are lazily restored for user processes.

This series proposes to fix this by wrapping all runtime services calls, and
adding kernel_neon_begin()/kernel_neon_end() pairs to the wrappers.

The first patch moves the existing x86 versions of those wrappers to generic
code, so that the second patch can easily enable them by supplying a definition
for  efi_call_virt and adding a call to efi_native_runtime_setup().

Ard Biesheuvel (2):
  efi/x86: move UEFI Runtime Services wrappers to generic code
  efi/arm64: preserve NEON registers on UEFI runtime services calls

 arch/arm64/include/asm/efi.h   |  21 ++
 arch/arm64/kernel/efi.c|  14 +---
 arch/x86/platform/efi/efi.c| 144 +--
 drivers/firmware/efi/Makefile  |   2 +-
 drivers/firmware/efi/runtime.c | 167 +
 include/linux/efi.h|   2 +
 6 files changed, 194 insertions(+), 156 deletions(-)
 create mode 100644 drivers/firmware/efi/runtime.c

-- 
1.8.3.2

--
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 0/2] efi: preserve NEON registers on UEFI services calls

2014-06-23 Thread Ard Biesheuvel 
On 23 June 2014 16:18, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 The current UEFI implementation for arm64 fails to preserve/restore the 
 contents
 of the NEON register file, which may result in data corruption, especially now
 that those contents are lazily restored for user processes.

 This series proposes to fix this by wrapping all runtime services calls, and
 adding kernel_neon_begin()/kernel_neon_end() pairs to the wrappers.

 The first patch moves the existing x86 versions of those wrappers to generic
 code, so that the second patch can easily enable them by supplying a 
 definition
 for  efi_call_virt and adding a call to efi_native_runtime_setup().


CC'ing Olivier and Mark (with correct email address this time).

Also, as an additional note, the UEFI spec section 2.3.6.4 mandates
that 'any additional execution state context' should be saved and
restored by the callee, which would imply that doing it in the kernel
is redundant. But current implementations of Tianocore/EDK2 don't seem
to honor that requirement, and considering GCC's tendency to spill
state to FPSIMD registers, we may choose to do so anyway to be on the
safe side.

-- 
Ard.

 Ard Biesheuvel (2):
   efi/x86: move UEFI Runtime Services wrappers to generic code
   efi/arm64: preserve NEON registers on UEFI runtime services calls

  arch/arm64/include/asm/efi.h   |  21 ++
  arch/arm64/kernel/efi.c|  14 +---
  arch/x86/platform/efi/efi.c| 144 +--
  drivers/firmware/efi/Makefile  |   2 +-
  drivers/firmware/efi/runtime.c | 167 
 +
  include/linux/efi.h|   2 +
  6 files changed, 194 insertions(+), 156 deletions(-)
  create mode 100644 drivers/firmware/efi/runtime.c

 --
 1.8.3.2

--
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 1/3] efi/reboot: Add generic wrapper around EfiResetSystem()

2014-06-23 Thread Mark Salter 
On Thu, 2014-06-19 at 14:40 +0100, Matt Fleming wrote:
 From: Matt Fleming matt.flem...@intel.com
 
 Implement efi_reboot(), which is really just a wrapper around the
 EfiResetSystem() EFI runtime service, but it does at least allow us to
 funnel all callers through a single location.
 
 It also simplifies the callsites since users no longer need to check to
 see whether EFI_RUNTIME_SERVICES are enabled.
 
 Cc: Tony Luck tony.l...@intel.com
 Cc: Mark Salter msal...@redhat.com
 Signed-off-by: Matt Fleming matt.flem...@intel.com
 ---

Tested-by: Mark Salter msal...@redhat.com

 
 Mark, I reworked my efi_reboot() to more closely match your versino.
 Since we essentially wrote the same code I'd be happy to include your
 chosen Copyright notice, I just didn't want to be presumptuous and do it
 on your behalf without asking.
 

Copyright (c) 2014 Red Hat, Inc., Mark Salter msal...@redhat.com

Thanks.


--
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 2/3] efi/reboot: Allow powering off machines using EFI

2014-06-23 Thread Mark Salter 
On Thu, 2014-06-19 at 14:40 +0100, Matt Fleming wrote:
 From: Matt Fleming matt.flem...@intel.com
 
 Not only can EfiResetSystem() be used to reboot, it can also be used to
 power down machines.
 
 By and large, this functionality doesn't work very well across the range
 of EFI machines in the wild, so it should definitely only be used as a
 last resort. In an ideal world, this wouldn't be needed at all.
 
 Unfortunately, we're starting to see machines where EFI is the *only*
 reliable way to power down, and nothing else, not PCI, not ACPI, works.
 
 efi_poweroff_required() should be implemented on a per-architecture
 basis, since exactly when we should be using EFI runtime services is a
 platform-specific decision. There's no analogue for reboot because each
 architecture handles reboot very differently - the x86 code in
 particular is pretty complex.
 
 Patches to enable this for specific classes of hardware will be
 submitted separately.
 
 Cc: Mark Salter msal...@redhat.com
 Signed-off-by: Matt Fleming matt.flem...@intel.com
 ---

Tested-by: Mark Salter msal...@redhat.com


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