On Thu, Apr 18, 2019 at 03:43:06PM +0100, Andrew Jones wrote: > On Thu, Apr 18, 2019 at 03:03:02PM +0100, Dave Martin wrote:
[...] > > It's worth nothing that there are two problems to be solved here: one is > > to specify an exact set unambiguously, which is important for migration > > scenarios. > > > > The other is to be able to clamp the vector length for user convenience, > > but without particularly considering migration. There's no direct way > > for the user to know the set of vector lengths supported by KVM today, > > so cooking up the right magic to go on the command line is non-trivial: > > you have to create a dummy vcpu and read KVM_REG_ARM64_SVE_VLS to find > > the host's supported set. Or you just have to know. > > Right, we'll have to query first to know what's available. libvirt will > do that and tools built on libvirt should help provide the user with > sane defaults or a relatively painless selection process. The QEMU command > line is primarily for developers, so they'll likely just know what they > want. > > > > > A separate max-vl option (or whatever) might be a useful alternative. > > Yeah, we could offer this to be nicer to QEMU command line users that > don't intend to migrate, or don't care if a migration can fail. This > would be analogous to '-cpu max' which enables all available cpu > features. Bad for migration, but a nice shorthand if you want your > guest to have everything. Sounds reasonable. Cheers ---Dave