Re: [Qemu-devel] How do we do user input bitmap properties?

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Dave Martin (Dave.Martin@arm.com) wrote:
> On Wed, May 15, 2019 at 09:18:54AM +0100, Andrew Jones wrote:
> > On Tue, May 14, 2019 at 04:48:38PM +0200, Igor Mammedov wrote:
> > > On Tue, 14 May 2019 11:02:25 +0200
> > > Andrew Jones <drjones@redhat.com> wrote:
> > > > My thought is primarily machines. If a human wants to use the command
> > > > line and SVE, then I'm assuming they'll be happy with sve-max-vq or
> > > > figuring out a map they like once and then sticking to it.
> > > 
> > > maybe naive question, but why not use a property/bit as user facing interface,
> > > in line with what we do with CPUID bits. (that's assuming that bits have
> > > fixed meaning).
> > > Yes, it's verbose but follows current practice and works fine with -cpu and
> > > -device.
> > > (I really hate custom preprocessing of -cpu and we were working hard to remove
> > > that in favor of canonical properties at the expense of more verbose CLI).
> > >
> > 
> > Are you asking if we should do something like the following?
> > 
> >   -cpu host,sve1=on,sve=2=on,sve3=off,sve4=on
> 
> Note, there is nothing SVE-specific about this.
> 
> Either enabling features on a per-vcpu basis is justified, or it isn't:
> if it's justified, then it would be better to have a general way of
> specifying per-vcpu properties, rather than it being reinvented per
> feature.

SVE *is* a bit unusual.  In most CPU features they're actually features,
they're on or off, so we have a big list of features that are
enabled/disabled.  We've had that type of thing (at least on x86) for
years and it's OK.
We've got one or two things where they're numerical
(e.g. host-physbits) and we struggle a bit with how to handle them.

SVE is somewhere in between - it's a list of numbers, apparently a
fairly large arbitrarily set of numbers that could be chosen so you'd
need lots of feature flags (sve1...sve64 say or more); so that doesn't
fit the existing things we've had that have worked.

Dave

> Creating mismatched configurations is allowed by the architecture and so
> it's useful for testing the kernel, but probably less useful for real-
> world use cases today.
> 
> So it may be a good idea to get the symmetric support sorted out first
> before thinking about whether and how to specify asymmetric
> configurations.
> 
> Cheers
> ---Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK