KVM: arm64: Treat FPEXC32_EL2 as a regular guest system register
Currently FPEXC32_EL2 is handled specially when context-switching.
However, FPEXC has no architectural effect when running in AArch64.
The only case where an arm64 host may execute in AArch32 is when
running compat user code at EL0: the architecture explicitly
documents FPEXC as having no effect in this case either when the
kernel (EL2 in the VHE case; otherwise EL1) is AArch64.
So, we can just handle FPEXC32_EL2 (which is the AArch64 alias for
this register) as a regular AArch32-only system register and switch
it without any special handling or synchronisation.
This allows some gnarly special-case code to be eliminated from
hyp. The extra isb() in __activate_traps_fpsimd32() is dropped
too: for the reasons explained above arm64 never required this
anyway.
Note that the comment in the deleted __activate_traps_fpsimd32()
function about the need to inhibit traps to EL1 is only meaningful
if the guest's value for FPEXC is not restored (thus potentially
causing an unexpected trap to EL1 in the guest unless we're careful
to set the EN bit). This arises from the treatment of FPEXC32_EL2
as if it were part of the the FPSIMD state to be switched lazily,
whereas it is really more natural to consider it as part of the EL1
system register state to be switched eagerly at the appropriate
times.
In fact, we explicitly don't care about seeing any trap until the
guest accesses the FPSIMD registers for real, provided that the
guest sees the behaviour it expects. So ensuring that the guest's
view of FPEXC is alawys up to date (as implemented by this patch)
should be sufficient. Since we always had to write FPEXC32_EL2
anyway (in order to work around the possibility of not restoring it
properly for the guest) this should not add significant cost. In
any case, this patch moves any cost off the hyp switch critical
path, to vcpu_load/put().
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Christoffer Dall <christoffer.dall@arm.com>
Cc: Alexander Graf <agraf@suse.de>
Signed-off-by:
Dave Martin <Dave.Martin@arm.com>
Loading
Please register or sign in to comment