On Wed, Sep 05, 2018 at 05:08:38PM +0200, Christoffer Dall wrote: > On Wed, Sep 05, 2018 at 02:19:13PM +0100, Dave Martin wrote: > > Currently FPEXC32_EL2 is handled specially when context-switching. > > This made sense for arm, where FPEXC affects host execution > > (including VFP/SIMD register save/restore at Hyp). > > > > 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. > > This looks like a reasonable cleanup, but I don't understand how this > works. The reason we had the special casing of FPXEC_EL2 was to ensure > that we trap to EL2 when VFP should be trapped for a 32-bit guest > instead of going to EL1. How does that work with this patch if we set Actually, I think the problem was to ensure that the guest never sees a spurious trap to EL1 when from its point of view FPEXC.EN is set. Such a trap shouldn't architecturally happen, but if we execute the guest with FPEXC.EN=0 when the guest thinks it should be 1 then a trap to EL1 can occur irrespective of CPTR_EL2, because CPTR_EL2 only traps things that wouldn't otherwise trap to EL1. > CPTR_EL2.TFP and the guest has set FPXEX32_EL2.EN ? I'm not sure whether that's the question you intended to ask: with EN set and TFP set, everything gets trapped to EL2, giving us a chance to switch in the FP regs, which sounds like the intended behaviour. I think the full set of relevant possibilities looks like this: TFP EN FPEXC fpregs 0 0 - EL1 0 1 - - 1 0 EL2 EL1 1 1 EL2 EL2 Here, "TFP" is CPTR_EL2.TFP (or VHE equivalent) and EN is FPEXC (or FPEXC32_EL2 depending on your point of view) . EN. The FPEXC and fpregs columns show what happens when attempting to access the FPEXC or other fp regs respectively from the guest. - indicates no trap taken, otherwise I list the destination EL for the trap. (assuming I've interpreted the rules correctly of course). Cheers ---Dave _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
