On Mon, May 13, 2019 at 11:46:29AM -0700, Richard Henderson wrote: > 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.
-cpu host can support whatever the host (hardware + KVM ) supports, but if a user doesn't want to expose all of it to the guest, then the user doesn't have to. For example, the host cpu may have a PMU, but the guest doesn't necessarily get one (-cpu host,pmu=off). > I really don't see how -cpu max makes any sense for > kvm. > It's already supported for kvm. This series just extends that support to match tcg's sve support. The reason it's supported is that you can then use '-cpu max' along with '-machine accel=kvm:tcg' in a command line and it'll just work. > > > 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. The guest's view of the hardware will be a single set. That set can be different for different guests though, within the constraints of the architecture and KVM or TCG implementations. > Whether VQ=3 is > valid or not is not going to depend on the maximum VQ, surely. Exactly. That's why we need a way to explicitly state what is supported. We can't assume anything from the max VQ alone. Additionally, while strict truncation is required now for KVM, things may be more flexible later. TCG is already more flexible. For TCG, all sets that at least include all the power-of-2 lengths up to the maximum VQ are valid, as the architecture states. Plus, all the sets that can be derived by adding one ore more optional lengths to those sets are also valid. Listing each of them allows management software to know what's going to work and what's not without having to know all the rules itself. > > 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. > I agree. The changes won't be small to QEMU, but hopefully we can design a QMP query that won't need to change, saving libvirt some pain. Thanks, drew
