QEMU's dump-guest-memory should handle SVE registers when SVE is enabled in the guest. target/arm/arch_dump.c needs to be extended for this. This enables 'virsh dump' to work properly for an SVE-enabled guest.
I posted[*] this a while back, and it's been reviewed. Just waiting on more review and merge now. [*] https://patchwork.kernel.org/patch/11193797/
This is now upstream: 538baab245ca ("target/arm/arch_dump: Add SVE notes")
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
Created attachment 1668177 [details] program to load sve vectors This bug may be moved to VERIFIED. Version tested: qemu-kvm-4.2.0-12.module+el8.2.0+5858+afd073bc.aarch64 Verification steps ------------------ 1) Get host notes (On a host that supports at least 64 byte SVE vectors) # ulimit -c unlimited # echo kcore > /proc/sys/kernel/core_pattern # ./v 64 & # kill -s SIGSEGV <pid-of-v> # readelf -n kcore.<pid-of-v> (repeat above for './v 32' and './v 0') 2) Get guest notes a) boot guest with sve enabled and with the same vector lengths as the host b) on guest run ./v 64 c) on host run 'virsh dump --memory-only $GUEST guest-dump-64' d) on guest stop ./v with ^C e) on host 'readelf -n guest-dump-64' (repeat above for './v 32' and './v 0') 3) Collect the note description data of the 0x405 (Unknown note type: (0x00000405)) ELF notes for all the runs 4) Compare the data for the same run types, e.g. 'diff kcore-64.405-data guest-dump-64.405-data' All comparisons should match, i.e. the ELF note generated by QEMU for SVE vectors should match the ELF note generated by the kernel for the same vector use. With qemu-kvm-4.2.0-12.module+el8.2.0+5858+afd073bc.aarch64 this test PASSed.
Thanks Drew!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:2017