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 ]
It doesn't really matter for this discussion, but I just realized that I picked bogus numbers for these examples. 32 would be too big. The largest supported is 16. I probably should have just used the simple [ 1, 2, 4 ] and [ 1, 2, 3, 4 ] arrays, corresponding to vector lengths (in bits) 128, 256, 512 and 128, 256, 384, 512. > > 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. > > Thanks, > drew