arm64: set FPEN if we're stuck with HCR_EL2.E2H

[kevans]

Summary

On Apple Silicon systems, E2H can't actually be cleared; we're stuck
with it. Check it again when we're setting up CPTR_EL2 and set FPEN
appropriately to avoid later trapping to EL2 on writes to SIMD
registers.

[andrew]

sys/arm64/arm64/locore.S

264

I think we'll need an isb between setting hcr_el2 and reading it to ensure the change is visible to instructions after it (i.e. the mrs)

sys/arm64/include/hypervisor.h

51

We should have two sets of macros. The current ones are only valid when HCR_EL2.E2H == 0. TTA and TCPAC are the only macros that are shared between the two.

95–96

This is normally named ..._SHIFT in this file and armreg.h

[kevans]

Address review commentary:

• Add an isb
• Follow convention for shift naming

I also went back to https://developer.arm.com/documentation/ddi0601/2020-12/AArch64-Registers/CPTR-EL2--Architectural-Feature-Trap-Register--EL2-
and discovered where I misunderstood the differences (the second table depicting
HCR_EL2.E2H == 0 didn't stick out on my first read, so there was some confusion
there) -- for E2H == 1, we shouldn't be using CPTR_RES1 at all as there are no
RES1 bits.

[andrew]

sys/arm64/arm64/locore.S

282–297

I think you can write this as (but might have x3 and x4 backwards in the csel instruction):

tst     x4, #HCR_E2H
mov     x3, #CPTR_RES1
mov     x4, #CPTR_FPEN
csel    x2, x3, x4, eq

[kevans]

sys/arm64/arm64/locore.S

282–297

Ah, that's much cleaner, thanks! I've confirmed that it still works as expected on both an M1 as well as a Mt. Snow; reverted the HCR_* part of the hypervisor.h changes and will commit soon.