Re: [Q] arm: SVE accesses at EL0 is broken with E2H+TGE?

[Richard Henderson <richard.henderson@linaro.org>]

On 1/13/22 2:03 PM, Zenghui Yu wrote:
> Hi,
> 
> I've just exercised the SVE emulation in QEMU with
> 
> | `qemu-system-aarch64 -M virt,virtualization=on,gic-version=3 \
> |  -cpu max -accel tcg [...]`
> 
> Since QEMU sets ID_AA64MMFR1_EL1.VH for -cpu max, the Linux guest I use
> was booting with VHE enabled and running with E2H+TGE. But I've then
> seen the Linux sve-probe-vls selftest [1] failure in guest which runs at
> EL0 and can be described as:
> 
> 1) Call prctl(PR_SVE_SET_VL, vl == 64) to set the vector length.
> 2) Emit RDVL instruction **but** get vl == 16. Emmm..
> 
> Looking a bit further at the way we emulate SVE in QEMU, there might be
> some issues need to be addressed.
> 
> * sve_zcr_len_for_el() implementation
> 
> Per DDI 0584 B.a, when HCR_EL2.{E2H,TGE} == {1,1} and EL2 is enabled in
> the current Security state, ZCR_EL1 has no effect on execution at EL0.
> We should use ZCR_EL2 instead for E2H+TGE.
> 
> * CPTR_EL2 register accessors
> 
> CPTR_EL2 has diffrent layout with or without VHE, but looks like we only
> take the nVHE one into account. Take sve_exception_el(env, el == 0) as
> an example, we don't check CPTR_EL2.ZEN for EL0 SVE accesses and we will
> never generate an exception even if needed...
> 
> ... whilst Linux kernel indeed relies on a trap to EL2 to restore SVE
> context appropriately for userland. SVE accesses at EL0 is broken in
> that case, I guess?

Correct on both.  Thanks for the detailed report.


r~