qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrew Jones
Subject: Re: [Qemu-devel] How do we do user input bitmap properties?
Date: Wed, 15 May 2019 13:54:13 +0200
User-agent: NeoMutt/20180716

On Wed, May 15, 2019 at 12:52:29PM +0200, Igor Mammedov wrote:
> On Wed, 15 May 2019 10:18:54 +0200
> Andrew Jones <address@hidden> 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 <address@hidden> 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
> > 
> > (Where the numbers represent the number of vector quadwords supported.)
> 
> something like this, but why not replace 1,2,... with more meaning full
>  sve-encrypt/sve-something-else/...
> since using magic numbers is not very descriptive
> (but if there is some spec where they come from that we could point users to
> it might be acceptable too, but I'd reserve number approach for values only).

The numbers aren't magic, they're part of the name. '1' in the above
'sve1' means one quadword. It would probably have been better to use bits
instead in the example, i.e.

  -cpu host,sve128=on,sve256=on,sve384=off,sve512=on

where it's now clear that "sve512" has an analogy with x86's "avx512".

> 
> > Naturally that would work, but it would be super verbose and require
> > adding tons of properties.
> yep, it's not very (human) user friendly but that's what mgmt applications
> are for and well users always can prepare a script for long CLI and use
> whatever abstractions they could think of.
> 

So I set off to convince Igor of the wide word idea (he sits next to me,
so I didn't have go far), but he has convinced me of the above property
idea. He used the magic phrase: "less code would be needed". If we use
the properties like above then we get introspection for free (cpu property
listing which libvirt already knows how to do) - so no QMP query needed.
The cost is adding several properties (16 to handle the current 2048-bit
limit), but I guess that's cheap enough. The command line is verbose, but
also much easier for a human to construct and read. I'm pretty sold on
this path, but adding Andrea and Eduardo for their input as well.

Thanks,
drew



reply via email to

[Prev in Thread] Current Thread [Next in Thread]