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?
Thanks,
Zenghui
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/arm64/fp/sve-probe-vls.c
