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: Thu, 18 Apr 2019 17:09:28 +0200
User-agent: NeoMutt/20180716

On Thu, Apr 18, 2019 at 12:26:10PM +0100, Daniel P. Berrangé wrote:
> On Thu, Apr 18, 2019 at 11:28:41AM +0200, Andrew Jones wrote:
> > Hi all,
> > 
> > First some background:
> > 
> > For the userspace side of AArch64 guest SVE support we need to
> > expose KVM's allowed vector lengths bitmap to the user and allow
> > the user to choose a subset of that bitmap. Since bitmaps are a
> > bit awkward to work with then we'll likely want to expose it as
> > an array of vector lengths instead. Also, assuming we want to
> > expose the lengths as number-of-quadwords (quadword == 128 bits
> > for AArch64 and vector lengths must be multiples of quadwords)
> > rather than number-of-bits, then an example array (which will
> > always be a sequence) might be
> > 
> >  [ 8, 16, 32 ]
> > 
> > The user may choose a subsequence, but only through truncation,
> > i.e. [ 8, 32 ] is not valid, but [ 8, 16 ] is.
> > 
> > Furthermore, different hosts may support different sequences
> > which have the same maximum. For example, if the above sequence
> > is for Host_A, then Host_B could be
> > 
> >  [ 8, 16, 24, 32 ]
> > 
> > The host must support all lengths in the sequence, which means
> > that while Host_A supports 32, since it doesn't support 24 and
> > we can only truncate sequences, we must use either [ 8 ] or
> > [ 8, 16 ] for a compatible sequence if we intend to migrate
> > between the hosts.
> > 
> > Now to the $SUBJECT question:
> > 
> > My feeling is that we should require the sequence to be
> > provided on the command line as a cpu property. Something
> > like
> > 
> >   -cpu host,sve-vl-list=8:16
> > 
> > (I chose ':' for the delimiter because ',' can't work, but
> > if there's a better choice, then that's fine by me.)
> > 
> > Afaict a property list like this will require a new parser,
> > which feels a bit funny since it seems we should already
> > have support for this type of thing somewhere in QEMU. So,
> > the question is: do we? I see we have array properties, but
> > I don't believe that works with the command line. Should we
> > only use QMP for this? We already want some QMP in order to
> > query the supported vector lengths. Maybe we should use QMP
> > to set the selection too? But then what about command line
> > support for developers? And if the property is on the command
> > line then we don't have to add it to the migration stream.
> 
> You should be able to use arrays from the CLI with QemuOpts by repeating
> the same option name many times, though I can't say it is a very
> nice approach if you have many values to list as it gets very repetative.
> That's the curse of not having a good CLI syntax for non-scalar data in
> QemuOpts & why Markus believes we should switch to JSON for the CLI too
> 
>      -cpu host,sve-vl=8,sve-vl=16

This might be OK if it integrates nicely with QMP, etc, as the need for
a more verbose command line may be better than adding another parser,
etc. that Markus will have to rework someday :) Can you point me to a
property that needs/uses this already so I can look at its code?

Thanks,
drew



reply via email to

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