Hello all,
This is an attempt to get some clarification on the requirement for the kernel to preserve the state of the NEON register file before calling into UEFI runtime services.
According to the generic Procedure Call Standard for AArch64, only the lower 64-bits of registers q8 .. q15 need to be preserved by the callee. There are further constraints in the UEFI spec which are defined as:
2.3.6.4 Detailed Calling Convention The base calling convention for the AArch64 binding is defined in the document Procedure Call Standard for the ARM 64-bit Architecture Version A-0.06 (or later): http://infocenter.arm.com/ This binding further constrains the calling convention in these ways: . The AArch64 execution state must not be modified by the callee. . All code exits, normal and exceptional, must be from the A64 instruction set. . Floating point and SIMD instructions may be used. . Optional vector operations and other instruction set extensions may only be used: - After dynamically checking for their existence. - Saving and then later restoring any additional execution state context. - Additional feature enablement or control, such as power, must be explicitly managed. . Only little endian operation is supported. . The stack will maintain 16 byte alignment. . Structures (or other types larger than 64-bits) must be passed by reference and not by value. . The EFI AArch64 platform binding defines the platform register (r18) as “do not use”. Avoiding use of r18 in firmware makes the code compatible with both a fixed role for r18 defined by the OS platform ABI and the use of r18 by the OS and its applications as a temporary register.
IIUC floating point is mandatory in the v8 spec, which would imply that they should not be considered to be 'optional vector operations and other instruction set extensions', which would mean that the normal AAPCS rules apply, i.e., that the callee can clobber q0 .. q7 and q16 .. q31.
Any thoughts?
On 25 June 2014 12:21, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
Hello all,
This is an attempt to get some clarification on the requirement for the kernel to preserve the state of the NEON register file before calling into UEFI runtime services.
According to the generic Procedure Call Standard for AArch64, only the lower 64-bits of registers q8 .. q15 need to be preserved by the callee. There are further constraints in the UEFI spec which are defined as:
2.3.6.4 Detailed Calling Convention The base calling convention for the AArch64 binding is defined in the document Procedure Call Standard for the ARM 64-bit Architecture Version A-0.06 (or later): http://infocenter.arm.com/ This binding further constrains the calling convention in these ways: . The AArch64 execution state must not be modified by the callee. . All code exits, normal and exceptional, must be from the A64 instruction set. . Floating point and SIMD instructions may be used. . Optional vector operations and other instruction set extensions may only be used:
- After dynamically checking for their existence.
- Saving and then later restoring any additional execution state context.
- Additional feature enablement or control, such as power, must be
explicitly managed. . Only little endian operation is supported. . The stack will maintain 16 byte alignment. . Structures (or other types larger than 64-bits) must be passed by reference and not by value. . The EFI AArch64 platform binding defines the platform register (r18) as “do not use”. Avoiding use of r18 in firmware makes the code compatible with both a fixed role for r18 defined by the OS platform ABI and the use of r18 by the OS and its applications as a temporary register.
IIUC floating point is mandatory in the v8 spec, which would imply that they should not be considered to be 'optional vector operations and other instruction set extensions', which would mean that the normal AAPCS rules apply, i.e., that the callee can clobber q0 .. q7 and q16 .. q31.
Another bit that may be relevant, from the ARM ARM, section A1.5
""" All systems that support standard operating systems with rich application environments provide hardware support for floating-point and Advanced SIMD. It is a requirement of the ARM Procedure Call Standard for AArch64, see Procedure Call Standard for the ARM 64-bit Architecture. """
In other words, floating point and SIMD are not mandatory in general in v8, but they are mandatory for systems adhering to the 64-bit procedure call standard, which is mentioned explicitly in the UEFI spec.
This. and the fact that 'floating point and SIMD instructions' are mentioned separately from 'optional vector operations and other instruction set extensions' in the UEFI spec, makes a strong case for doing a preserve and restore in the kernel IMO.
-
Ard Biesheuvel