Prior to 7b6a2198e71794c851f39ac7a92d39692c786820, the QEMU option sve-max-vq could be used to set the vector length of the implementation. This is useful (among other reasons) for testing software compiled with a fixed SVE vector length. Since this commit, the vector length is capped at 512 bits.
To reproduce the issue:
$ cat rdvl.s
.global _start
_start:
rdvl x0, #1
asr x0, x0, #4
mov x8, #93 // exit
svc #0
$ aarch64-linux-gnu-as -march=armv8.2-a+sve rdvl.s -o rdvl.o
$ aarch64-linux-gnu-ld rdvl.o
$ for vl in 1 2 4 8 16; do ../build-qemu/aarch64-linux-user/qemu-aarch64 -cpu max,sve-max-vq=$vl a.out; echo $?; done
1
2
4
4
4
For a QEMU built prior to the above revision, we get the output:
1
2
4
8
16
as expected. It seems that either the old behavior should be restored, or there should be an option to force a higher vector length?
Hi Alex,
This commit mentions:
The Linux kernel chooses the default of 64 bytes for SVE registers on
the basis that it is the largest size on known hardware that won't
grow the signal frame. We still honour the sve-max-vq property and
userspace can expand the number of lanes by calling PR_SVE_SET_VL.
Expand the number of lanes by calling PR_SVE_SET_VL works for me:
.global _start
_start:
mov x0, 50 // PR_SVE_SET_VL
mov x1, 256 // 16 lanes
mov x8, #167 // prctl
svc #0
rdvl x0, #1
asr x0, x0, #4
mov x8, #93 // exit
svc #0
$ for vl in 1 2 4 8 16; do qemu-aarch64 -strace -cpu max,sve-max-vq=$vl a.out; echo $?; done
1383321 prctl(50,
1383321 exit(1)
1
1383323 prctl(50,
1383323 exit(2)
2
1383325 prctl(50,
1383325 exit(4)
4
1383327 prctl(50,
1383327 exit(8)
8
1383329 prctl(50,
1383329 exit(16)
16