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

[Peter Maydell]

On 13 December 2017 at 16:55, Dave Martin <Dave.Martin at arm.com> 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.

thanks
-- PMM