According to the UEFI spec section 2.3.6.4, the use of FP/SIMD instructions is
allowed, and should adhere to the AAPCS64 calling convention, which states that
'only the bottom 64 bits of each value stored in registers v8-v15 need to be
preserved' (section 5.1.2).
This applies equally to UEFI Runti
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
---
arch/x86/Kconfig| 1 +
arch/x86/platform/efi/efi.c | 144 +---
Two patches to add FP/SIMD preserve/restore to UEFI Runtime Services:
- patch #1 moves runtime services wrappers to generic code so we can reuse them
for arm64
- patch #2 enables the wrappers for arm64 and inserts calls to kernel_neon_begin
and kernel_neon_end
@Matt: please queue up for 3.17
On 4 July 2014 19:01, Catalin Marinas wrote:
> On Fri, Jul 04, 2014 at 05:52:36PM +0100, Mark Salter wrote:
>> On Fri, 2014-07-04 at 17:25 +0200, Ard Biesheuvel wrote:
>> > If we cannot resolve the virtual address of the UEFI System Table, its
>> > physical
>> > offset must be missing from the vi
On 4 July 2014 18:59, Catalin Marinas wrote:
> On Fri, Jul 04, 2014 at 04:51:31PM +0100, Ard Biesheuvel wrote:
>> On 4 July 2014 17:45, Catalin Marinas wrote:
>> > On Thu, Jun 26, 2014 at 11:09:06AM +0100, Ard Biesheuvel wrote:
>> >> According to the UEFI spec section 2.3.6.4, the use of FP/SIMD
On Fri, Jul 04, 2014 at 05:52:36PM +0100, Mark Salter wrote:
> On Fri, 2014-07-04 at 17:25 +0200, Ard Biesheuvel wrote:
> > If we cannot resolve the virtual address of the UEFI System Table, its
> > physical
> > offset must be missing from the virtual memory map, and there is really no
> > point
On Fri, Jul 04, 2014 at 04:51:31PM +0100, Ard Biesheuvel wrote:
> On 4 July 2014 17:45, Catalin Marinas wrote:
> > On Thu, Jun 26, 2014 at 11:09:06AM +0100, Ard Biesheuvel wrote:
> >> According to the UEFI spec section 2.3.6.4, the use of FP/SIMD
> >> instructions is
> >> allowed, and should adhe
On Fri, 2014-07-04 at 17:25 +0200, Ard Biesheuvel wrote:
> If we cannot resolve the virtual address of the UEFI System Table, its
> physical
> offset must be missing from the virtual memory map, and there is really no
> point
> in proceeding with installing the virtual memory map and the runtime
On 4 July 2014 17:45, Catalin Marinas wrote:
> On Thu, Jun 26, 2014 at 11:09:06AM +0100, Ard Biesheuvel wrote:
>> According to the UEFI spec section 2.3.6.4, the use of FP/SIMD instructions
>> is
>> allowed, and should adhere to the AAPCS64 calling convention, which states
>> that
>> 'only the b
On Thu, Jun 26, 2014 at 11:09:06AM +0100, Ard Biesheuvel wrote:
> According to the UEFI spec section 2.3.6.4, the use of FP/SIMD instructions is
> allowed, and should adhere to the AAPCS64 calling convention, which states
> that
> 'only the bottom 64 bits of each value stored in registers v8-v15 n
On Fri, Jul 04, 2014 at 02:54:19PM +0100, Ard Biesheuvel wrote:
> On 4 July 2014 15:38, Catalin Marinas wrote:
> > On Wed, Jul 02, 2014 at 11:10:01AM +0100, Ard Biesheuvel wrote:
> >> We assign efi.systab using efi_lookup_mapped_addr(), and test for !NULL,
> >> but
> >> then go on an dereference
If we cannot resolve the virtual address of the UEFI System Table, its physical
offset must be missing from the virtual memory map, and there is really no point
in proceeding with installing the virtual memory map and the runtime services
dispatch table. So back out gracefully.
Signed-off-by: Ard
(adding Catalin)
On 4 July 2014 16:42, Mark Salter wrote:
> On Fri, 2014-07-04 at 12:16 +0200, Ard Biesheuvel wrote:
>> If we cannot resolve the virtual address of the UEFI System Table, its
>> physical
>> offset must be missing from the virtual memory map, and there is really no
>> point
>> in
On Fri, 2014-07-04 at 12:16 +0200, Ard Biesheuvel wrote:
> If we cannot resolve the virtual address of the UEFI System Table, its
> physical
> offset must be missing from the virtual memory map, and there is really no
> point
> in proceeding with installing the virtual memory map and the runtime
On 4 July 2014 15:38, Catalin Marinas wrote:
> On Wed, Jul 02, 2014 at 11:10:01AM +0100, Ard Biesheuvel wrote:
>> We assign efi.systab using efi_lookup_mapped_addr(), and test for !NULL, but
>> then go on an dereference it anyway.
>>
>> Signed-off-by: Ard Biesheuvel
>
> Thanks. I applied this one
On Wed, Jul 02, 2014 at 11:10:01AM +0100, Ard Biesheuvel wrote:
> We assign efi.systab using efi_lookup_mapped_addr(), and test for !NULL, but
> then go on an dereference it anyway.
>
> Signed-off-by: Ard Biesheuvel
Thanks. I applied this one (the other patch needs to go in via a
different route
If we cannot resolve the virtual address of the UEFI System Table, its physical
offset must be missing from the virtual memory map, and there is really no point
in proceeding with installing the virtual memory map and the runtime services
dispatch table. So back out gracefully.
Signed-off-by: Ard
17 matches
Mail list logo
