Re: [libvirt] [RFC v2] arm64: KVM: KVM API extensions for SVE

On 13 December 2017 at 16:55, Dave Martin <Dave.Martin(a)arm.com&gt; wrote: > Vector length control: > > Some means is needed to determine the set of vector lengths visible > to guest software running on a vcpu. > > When a vcpu is created, the set would be defaulted to the maximal set > that can be supported while permitting each vcpu to run on any host > CPU. SVE has some virtualisation quirks which mean that this set may > exclude some vector lengths that are available for host userspace > applications. The common case should be that the sets are the same > however. > > * New ioctl KVM_ARM_VCPU_{SET,GET}_SVE_VLS to set or retrieve the set of > vector lengths available to the guest. > > Adding random vcpu ioctls > > To configure a non-default set of vector lengths, > KVM_ARM_VCPU_SET_SVE_VLS can be called: this would only be permitted > before the vcpu is first run. > > This is primarily intended for supporting migration, by providing a > robust check that the destination node will run the vcpu correctly. > In a cluster with non-uniform SVE implementation across nodes, this > also allows a specific set of VLs to be requested that the caller > knows is usable across the whole cluster. > > For migration purposes, userspace would need to do > KVM_ARM_VCPU_GET_SVE_VLS at the origin node and store the returned > set as VM metadata: on the destination node, > KVM_ARM_VCPU_SET_SVE_VLS should be used to request that exact set of > VLs: if the destination node can't support that set of VLs, the call > will fail. Can we just do this with the existing ONE_REG APIs? If you expose this via those, then QEMU doesn't need to do anything for migration at all. This is the same way we (intend to) check any optional-feature compatibility at each end, for instance features exposed in guest-visible ID registers. It's just that the "register" for the SVE vector-lengths case is one that's not visible to the guest.