On Wed, Sep 05, 2018 at 05:03:21PM +0200, Christoffer Dall wrote: > On Wed, Sep 05, 2018 at 12:28:46PM +0100, Dave Martin wrote: [...] > > You can try taking a look at the archietctural pseudocode -- see the > > CheckFPAdvSIMDEnabled64() (for AArch64) and CheckFPAdvSIMDEnabled() (for > > AArch32) function hierarchies on developer.arm.com. > > > > ARM DDI 0487B.b says for FPEXC32_EL2: > > > > "Purpose: Allows access to the AArch32 register FPEXC from AArch64 > > state only. Its value has no effect on execution in AArch64 state." > > > > This could arguably be worded better, but the second sentence is > > pretty unequivocal. > > > > I think I was confused about your point. I thought you were arguing > that CPTR_EL2.TFP==1 + FPEXC_EL2.EN==0, and running in AArch32 EL1+EL0, > and accessing VFP at EL0 would trap to EL2, when in fact it traps to > EL1. But now I think you're arguing that EL2 is unaffected by > FPEXC32_EL2, and I agree with that. > > However, given the above, I don't understand how we can let the guest be > in control of FPEXC, if we want to make sure we trap VFP accesses? If the guest set FPEXC.EN to 0, then it is expecting its own VFP accesses to trap to EL1. If a VFP access attempt traps to EL1 and the guest is expecting it, why does hyp need to get involved? Hyp only needs to interfere when an otherwise untrapped access to the VFP state would occur. If we don't have the guest context loaded, we would still trap any attempt by the guest to modify FPEXC to EL2 as a result of CPTR_EL2.TFP still being set (or equivalent). Cheers ---Dave
