Re: [Xen-devel] [PATCH v5 2/7] efi: Introduce EFI_NO_DIRECT flag

2014-06-16 Thread David Vrabel
On 13/06/14 18:00, Daniel Kiper wrote: Introduce EFI_NO_DIRECT flag. EFI_PARAVIRT would be a clearer name I think. +#define EFI_NO_DIRECT6 /* Can we access EFI directly? */ #define EFI_PARAVIRT 6 /* Access is via a paravirt interface */ David -- To unsubscribe from

Re: [PATCH v5 7/7] arch/x86: Comment out efi_set_rtc_mmss()

2014-06-16 Thread Stefano Stabellini
On Fri, 13 Jun 2014, Daniel Kiper wrote: efi_set_rtc_mmss() is never used to set RTC due to bugs found on many EFI platforms. It is set directly by mach_set_rtc_mmss(). Signed-off-by: Daniel Kiper daniel.ki...@oracle.com --- arch/x86/platform/efi/efi.c |6 ++ 1 file changed, 6

Re: [Xen-devel] [PATCH v5 7/7] arch/x86: Comment out efi_set_rtc_mmss()

2014-06-16 Thread Juergen Gross
On 06/16/2014 01:43 PM, Stefano Stabellini wrote: On Fri, 13 Jun 2014, Daniel Kiper wrote: efi_set_rtc_mmss() is never used to set RTC due to bugs found on many EFI platforms. It is set directly by mach_set_rtc_mmss(). Signed-off-by: Daniel Kiper daniel.ki...@oracle.com ---

Re: [PATCH v5 4/7] xen: Put EFI machinery in place

2014-06-16 Thread Stefano Stabellini
On Fri, 13 Jun 2014, 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

Re: [PATCH v5 4/7] xen: Put EFI machinery in place

2014-06-16 Thread David Vrabel
On 13/06/14 18:00, Daniel Kiper wrote: v5 - suggestions/fixes: Put after a --- marker. +static efi_char16_t vendor[100] __initdata; Why 100? 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

[RFC PATCH 1/4] efi/x86: efistub: move shared dependencies to asm/efi.h

2014-06-16 Thread Ard Biesheuvel
This moves definitions depended upon both by code under arch/x86/boot and under drivers/firmware/efi to asm/efi.h. This is in preparation of turning the stub code under drivers/firmware/efi into a static library. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org ---

[RFC PATCH 3/4] efi: efistub: refactor stub components

2014-06-16 Thread Ard Biesheuvel
In order to move from the #include ../../../x.c anti-pattern used by both the x86 and arm64 versions of the stub to a static library linked into either the kernel proper (arm64) or a separate boot executable (x86), there is some prepatory work required. This patch does the following: - move

Re: [RFC PATCH 4/4] efi: efistub: convert into static library

2014-06-16 Thread Ard Biesheuvel
On 16 June 2014 17:14, Ard Biesheuvel ard.biesheu...@linaro.org wrote: This patch changes both x86 and arm64 efistub implementations from #including shared .c files under drivers/firmware/efi to building the shared code as a static library. The x86 code uses a stub built into the boot

Re: [PATCH v5 4/7] xen: Put EFI machinery in place

2014-06-16 Thread Daniel Kiper
On Mon, Jun 16, 2014 at 12:55:35PM +0100, Stefano Stabellini wrote: On Fri, 13 Jun 2014, 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

Re: [Xen-devel] [PATCH v5 7/7] arch/x86: Comment out efi_set_rtc_mmss()

2014-06-16 Thread H. Peter Anvin
On 06/16/2014 04:54 AM, Juergen Gross wrote: And shouldn't it be removed from include/linux/efi.h as well? Indeed. -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

Re: [PATCH v5 4/7] xen: Put EFI machinery in place

2014-06-16 Thread Daniel Kiper
On Mon, Jun 16, 2014 at 01:00:29PM +0100, David Vrabel wrote: On 13/06/14 18:00, Daniel Kiper wrote: v5 - suggestions/fixes: Put after a --- marker. Why? You mean: --- v5 - suggestions/fixes: ... +static efi_char16_t vendor[100] __initdata; Why 100? Well... Quite arbitrary value.