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?