On Sun, 12 May 2019 at 09:36, Andrew Jones <drjo...@redhat.com> wrote: > > With the recent KVM guest SVE support pull request [1] KVM will be > ready for guests with SVE. This series provides the QEMU bits for > that enablement. The series starts with the bits needed for the KVM > SVE ioctls. Then it enables the arm 'max'cpu type, which with TCG > already supports SVE, to also support SVE when using KVM. Next > a new QMP query is added that allows users to ask which vector > lengths are supported by the host, allowing them to select a valid > set of vectors for the guest. In order to select those vectors a > new property 'sve-vls-map' is added to the 'max' cpu type, and then > also to the 'host' cpu type. The table below shows the resulting user > interfaces. > > CPU type | accel | sve-max-vq | sve-vls-map > ------------------------------------------- > 1) max | tcg | $MAX_VQ | $VLS_MAP > 2) max | kvm | $MAX_VQ | $VLS_MAP > 3) host | kvm | N/A | $VLS_MAP > > Where for (1) $MAX_VQ sets the maximum vq and smaller vqs are > all supported when $VLS_MAP is zero, or when the vqs are selected > in $VLS_MAP. > > (2) is the same as (1) except KVM has the final say on what > vqs are valid. > > (3) doesn't accept sve-max-vq because a guest that uses this > property without sve-vls-map cannot be safely migrated.
Is this "migrated between two hosts with the same host CPU type but with different kernel versions which expose different subsets of the host's permitted vector lengths" ? thanks -- PMM
