On Mon, 11 Apr 2022 at 13:02, Andrew Jones <drjo...@redhat.com> wrote: > > On Mon, Apr 11, 2022 at 10:22:59AM +0100, Peter Maydell wrote: > > Also, we support SVE today, and we don't have variable size > > coprocessor registers. Is there a bug here that we would be > > fixing ? > > SVE registers are KVM_REG_SIZE_U2048 and KVM_REG_SIZE_U256 sized > registers. They work fine (just like the VFP registers which are > KVM_REG_SIZE_U128 sized). They work because they don't get stored in the > cpreg list. SVE and CORE (which includes VFP) registers are filtered > out by kvm_arm_reg_syncs_via_cpreg_list(). Since they're filtered > out they need to be handled specifically by kvm_arch_get/put_registers()
Right, this is the distinction between ONE_REG registers and coprocessor registers (which are a subset of ONE_REG registers). We wouldn't want to handle SVE regs in the copro list anyway, I think, because we want their state to end up in env->vfp.zregs[] so the gdbstub can find it there. And we wouldn't have benefited from the copro regs handling's "no need for new QEMU to handle migrating state of a new register" because we needed a lot of special case code for SVE and couldn't enable it by default for other reasons. If we do add non-64-bit cpregs on the kernel side then we need to make those new registers opt-in, because currently deployed QEMU will refuse to start if the kernel passes it a register in the KVM_GET_REG_LIST that is larger than 64 bits and isn't KVM_REG_ARM_CORE or KVM_REG_ARM64_SVE (assuming I'm not misreading the QEMU code). -- PMM