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
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 ard.biesheu...@linaro.org
Thanks. I applied this one (the other patch needs to go in
On 4 July 2014 15:38, Catalin Marinas catalin.mari...@arm.com 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
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
(adding Catalin)
On 4 July 2014 16:42, Mark Salter msal...@redhat.com 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
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
On Fri, Jul 04, 2014 at 02:54:19PM +0100, Ard Biesheuvel wrote:
On 4 July 2014 15:38, Catalin Marinas catalin.mari...@arm.com 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
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 need
On 4 July 2014 17:45, Catalin Marinas catalin.mari...@arm.com 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
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 Fri, Jul 04, 2014 at 04:51:31PM +0100, Ard Biesheuvel wrote:
On 4 July 2014 17:45, Catalin Marinas catalin.mari...@arm.com 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
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
in
On 4 July 2014 18:59, Catalin Marinas catalin.mari...@arm.com wrote:
On Fri, Jul 04, 2014 at 04:51:31PM +0100, Ard Biesheuvel wrote:
On 4 July 2014 17:45, Catalin Marinas catalin.mari...@arm.com wrote:
On Thu, Jun 26, 2014 at 11:09:06AM +0100, Ard Biesheuvel wrote:
According to the UEFI spec
On 4 July 2014 19:01, Catalin Marinas catalin.mari...@arm.com 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
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
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/Kconfig| 1 +
arch/x86/platform/efi/efi.c
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
17 matches
Mail list logo
