On 29 January 2015 at 09:50, Steve Capper wrote:
> On 8 January 2015 at 18:48, Ard Biesheuvel wrote:
>> In order to support kexec, the kernel needs to be able to deal with the
>> state of the UEFI firmware after SetVirtualAddressMap() has been called.
>> To avoid having separate code paths for no
On 8 January 2015 at 18:48, Ard Biesheuvel wrote:
> In order to support kexec, the kernel needs to be able to deal with the
> state of the UEFI firmware after SetVirtualAddressMap() has been called.
> To avoid having separate code paths for non-kexec and kexec, let's move
> the call to SetVirtualA
On Mon, 12 Jan, at 04:09:24PM, Ard Biesheuvel wrote:
>
> Cheers Matt
>
> It appears this series is converging in time for 3.20, but this patch
> still lacks acked/reviewed-bys
>
> Are you ok with the remainder of the patch as well? In that case, may
> I have your ack so the series can be merged
On 12 January 2015 at 11:46, Matt Fleming wrote:
> On Thu, 08 Jan, at 06:48:32PM, Ard Biesheuvel wrote:
>> @@ -46,4 +54,26 @@ extern void efi_idmap_init(void);
>>
>> #define EFI_ALLOC_ALIGN SZ_64K
>>
>> +/*
>> + * On ARM systems, virtually remapped UEFI runtime services are set up in
On Thu, 08 Jan, at 06:48:32PM, Ard Biesheuvel wrote:
> @@ -46,4 +54,26 @@ extern void efi_idmap_init(void);
>
> #define EFI_ALLOC_ALIGN SZ_64K
>
> +/*
> + * On ARM systems, virtually remapped UEFI runtime services are set up in
> three
> + * distinct stages:
> + * - The stub retr
On Thu, Jan 08, 2015 at 06:48:32PM +, Ard Biesheuvel wrote:
> In order to support kexec, the kernel needs to be able to deal with the
> state of the UEFI firmware after SetVirtualAddressMap() has been called.
> To avoid having separate code paths for non-kexec and kexec, let's move
> the call t
6 matches
Mail list logo
