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

[Andrew Jones]

On Tue, May 14, 2019 at 03:32:13PM +0200, Markus Armbruster wrote:
> Syntax that can support such growth would be nice.
> 
> To grow a single unsigned number, we can make it wider (but we don't
> have infrastructure for numbers wider than 64 bits), or we can add more
> numbers (but under what name?).
> 
> Dotted keys syntax could grow more easily, but it's rather awkward.
> 
> Looking more closely at your "[PATCH 11/13] target/arm/cpu64: max cpu:
> Introduce sve-vls-map"... your syntax reflects your data structure:
> property "sve-vls-map" is of type uint64_t, and interpreted as bit set.
> This data type would have to grow, too.
> 
> We could make widen the integer property (but we don't have
> infrastructure for integer properties wider than 64 bits), or we can
> turn it into an array of integers (compatibility?), or we can add more
> properties to hold the additional integers (yet another silly way to
> represent a list/array of integers).
> 
> I'm not asking you to complicate things just to future-proof this.  Just
> pause and think whether you can pick a data type that's similarly
> convenient now, and easier to grow.
> 
> Then pick an external syntax for this data type.  You may have to pick a
> reasonable compromise between ease of implementation and ease of use.

Widening the integer property sounds good to me. I just hadn't thought of
it (implementation tunnel vision affecting my user interface design).
Andrea also mentioned that as a possibility in a reply to the series. I
think we can leave the property as a uint64_t right now and then, when/if
it needs to expand past 64 bits we can change the property to a string
and start parsing arbitrarily large integers from it. The internal state,
'uint64_t sve_vls_map' can easily be changed to a 'uint64_t sve_vls_map[]'
at that point too. How's that sound?

> Primarily machines means we can accept more verbosity.
> 
> If I understand the cover letter of your "[PATCH 00/13] target/arm/kvm:
> enable SVE in guests" correctly, then sve-max-vq and sve-vls-map are
> alternative interfaces for the same thing.  The latter is more general,
> but awkward on the command line and verbose everywhere.  The former
> isn't usable with -cpu host.  Correct?
> 
> If there wasn't "not usable with -cpu host", I'd ask whether we really
> need the generality.
>

The 'not usable with -cpu host' was a choice, not a limitation to deal
with. The problem with sve-max-vq is that it doesn't provide enough
information by itself. Multiple vector sets with the same max-vq can be
valid. For migration of KVM guests the exact set needs to be explicitly
requested to ensure the host supports it. For TCG it may be nice to
model sets besides the everything up to max-vq set that sve-max-vq would
choose. sve-max-vq could be used with -cpu host the same way I've
implemented it for -cpu max, which is to take the fully supported vector
set from the KVM query and use that one, but I didn't want to encourage
its use with AArch64's primary KVM cpu type (even if it's -cpu host and
thus not a great choice for migration anyway).

Thanks,
drew