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

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

[Zenghui Yu via]

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

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

[Richard Henderson]

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~