On Mon, Jun 24, 2019 at 12:05:26PM +0100, Dave Martin wrote: > On Fri, Jun 21, 2019 at 05:34:15PM +0100, Andrew Jones wrote: > > Introduce cpu properties to give fine control over SVE vector lengths. > > We introduce a property for each valid length up to the current > > maximum supported, which is 2048-bits. The properties are named, e.g. > > sve128, sve256, sve512, ..., where the number is the number of bits. > > > > It's now possible to do something like -cpu max,sve-max-vq=4,sve384=off > > to provide a guest vector lengths 128, 256, and 512 bits. The resulting > > set must conform to the architectural constraint of having all power-of-2 > > lengths smaller than the maximum length present. It's also possible to > > only provide sve<vl-bits> properties, e.g. -cpu max,sve512=on. That > > example provides the machine with 128, 256, and 512 bit vector lengths. > > It doesn't hurt to explicitly ask for all expected vector lengths, > > which is what, for example, libvirt should do. > > > > Note1, it is not possible to use sve<vl-bits> properties before > > sve-max-vq, e.g. -cpu max,sve384=off,sve-max-vq=4, as supporting > > that overly complicates the user input validation. > > > > Note2, while one might expect -cpu max,sve-max-vq=4,sve512=on to be the > > same as -cpu max,sve512=on, they are not. The former enables all vector > > lengths 512 bits and smaller, while the latter only sets the 512-bit > > length and its smaller power-of-2 lengths. It's probably best not to use > > sve-max-vq with sve<vl-bits> properties, but it can't be completely > > forbidden as we want qmp_query_cpu_model_expansion to work with guests > > launched with e.g. -cpu max,sve-max-vq=8 on their command line. > > Supporting both options together in a non-idempotent way seems to > complicate things. > > Would it be simpler to allow sve-max-vq only when there are no sve<bits> > options?
Not really. Since we can't simply remove sve-max-vq from the 'max' cpu type, then we'd still need conditions to check when we can use it. The restriction that it has to come first reduces the complexity substantially, and I think restricting to not being allowed at all, when sve<vl-bits> are used, would only give us a net check reduction of one or two. > > Alternatively, the two options would be defined so that their meanings > are independent of parse order. > > So, way sve-max-vq=<max> means that: > > * all VQs up to max for which there is no corresponding sve<bits>=off, > are enabled; and > > * VQ max is enabled; and > > * all VQs exceeding max are disabled. > > While sve<bits>=(on|off) means > > * the VQ coresponding to <bits> is enabled (for on) or disabled (for > off). > > After parsing all the options, you check that the sve-max-vq and > sve<bits> optinos are consistent. If you disallow duplicate sve-max-vq > or sve<bits> options, then there is no possibility of ambiguity and the > order or options doesn't matter. I don't want to put any final checks at the end of parsing all options, because that won't work with the QMP query. > > (There may be constraints on the way qemu options parsing works that > make this hard, though...) I can't think of any issue with the parsing, but the QMP query only using the property get accessors, without any finalizing, does put constraints on what we can do. > > Having sve-max-vq in 128-bit units while sve<bits> are named in terms of > bit counts also feels a bit odd now. sve-max-vq already exists, so it'd have to be deprecated if we don't want it anymore. And I think sve<vl-bits> is the right naming to go with for that. Of course using sve-max-vq is completely optional. If you don't want it for backward compatible reasons, or as a shorthand to restrict the lengths, then you can just use the sve<vl-bits> properties. Indeed, with KVM, if you use the 'host' cpu type (the default for use with KVM), then you won't even have the sve-max-vq property. As 'host' never had it, I didn't have to keep it, nor adopt it. And of course I didn't want to adopt it. Thanks, drew