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

[Laszlo Ersek <lersek@redhat.com>]

On 04/18/19 11:28, 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 think so. OptsVisitor can parse repeated properties from an option and
turn them into a list that you define in QAPI schema. More precisely,
you'd define the schema first, subject to "rules" and "restrictions",
and then OptsVisitor would allow you to grab that schema from command
line options. A list of integers qualifies.

See for example:

[Qemu-devel] [PATCH v2 0/8] OptsVisitor: support / flatten integer range
https://lists.gnu.org/archive/html/qemu-devel/2013-08/msg02686.html

(this is actually a feature on top of what you seem to need, but this is
what I could find right now).

Although I worked on this stuff in 2012-2013 (and so I remember
basically nothing about it), it should still function, because the qtest
suite exercises it with good coverage.

So, suggestions:
- git show -s eb7ee2cb
- check how "-numa" is parsed, and steal it :)

If OptsVisitor is hard to combine with existent options that are already
parsed in a different manner (and I do think it would be difficult),
then a new option could be introduced. For example:

  -sve-vector-lengths allow=8,allow=16

which should give you an ordered list of lengths, and you could distill
that manually into a single bitmap.

Thanks,
Laszlo
PS: I do mean I don't remember anything about OptsVisitor :/

> 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.
> 
> Thanks,
> drew
>