On 5/12/19 1:36 AM, Andrew Jones wrote: > 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
This doesn't seem right. Why is -cpu host not whatever the host supports? It certainly has been so far. I really don't see how -cpu max makes any sense for kvm. > The QMP query returns a list of valid vq lists. For example, if > a guest can use vqs 1, 2, 3, and 4, then the following list will > be returned > > [ [ 1 ], [ 1, 2 ], [ 1, 2, 3 ], [ 1, 2, 3, 4 ] ] > > Another example might be 1, 2, 4, as the architecture states 3 > is optional. In that case the list would be > > [ [ 1 ], [ 1, 2 ], [ 1, 2, 4 ] ] > > This may look redundant, but it's necessary to provide a future- > proof query, because while KVM currently requires vector sets to > be strict truncations of the full valid vector set, that may change > at some point. How and why would that make sense? Real hardware is going to support one set of vector lengths. Whether VQ=3 is valid or not is not going to depend on the maximum VQ, surely. I'll also note that if we want to support the theoretical beyond-current-architecture maximum VQ=512, such that migration works seemlessly with current hardware, then we're going to have to change the migration format. So far I'm supporting only the current architecture maximum VQ=16. Which seemed plenty, given that the first round of hardware only supports VQ=4. r~