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~
