* [Q] arm: SVE accesses at EL0 is broken with E2H+TGE?
@ 2022-01-13 3:03 Zenghui Yu via
2022-01-25 22:08 ` Richard Henderson
0 siblings, 1 reply; 2+ messages in thread
From: Zenghui Yu via @ 2022-01-13 3:03 UTC (permalink / raw)
To: qemu-devel, qemu-arm
Cc: Richard Henderson, Peter Maydell, kernel.yuz, wanghaibin.wang
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Q] arm: SVE accesses at EL0 is broken with E2H+TGE?
2022-01-13 3:03 [Q] arm: SVE accesses at EL0 is broken with E2H+TGE? Zenghui Yu via
@ 2022-01-25 22:08 ` Richard Henderson
0 siblings, 0 replies; 2+ messages in thread
From: Richard Henderson @ 2022-01-25 22:08 UTC (permalink / raw)
To: Zenghui Yu, qemu-devel, qemu-arm
Cc: Peter Maydell, kernel.yuz, wanghaibin.wang
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~
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-01-25 22:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-13 3:03 [Q] arm: SVE accesses at EL0 is broken with E2H+TGE? Zenghui Yu via
2022-01-25 22:08 ` Richard Henderson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.