This is an automated cleanup. This bug report has been moved to QEMU's new bug tracker on gitlab.com and thus gets marked as 'expired' now. Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/482 ** Changed in: qemu Status: New => Expired ** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #482 https://gitlab.com/qemu-project/qemu/-/issues/482 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1906536 Title: Unable to set SVE VL to 1024 bits or above since 7b6a2198 Status in QEMU: Expired Bug description: 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? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1906536/+subscriptions
