On Wed, 2019-05-15 at 12:14 +0100, Dave Martin wrote: > On Wed, May 15, 2019 at 09:03:58AM +0100, Andrea Bolognani wrote: > > On Tue, 2019-05-14 at 13:14 -0700, Richard Henderson wrote: > > > Why is =4 less user-friendly than =512? > > > > > > I don't actually see "total bits in vector" as more user-friendly than > > > "number > > > of quadwords" when it comes to non-powers-of-2 like =7 vs =896 or =13 vs > > > =1664. > > > > I would wager most people are intimately familiar with bits, bytes > > and multiples due to having to work with them daily. Quadwords, not > > so much. > > Generally I tend to agree. For kvmtool I leaned torward quadwords > purely because > > 16,32,48,64,80,96,112,128,144,160,176,192,208 > > is a big pain to type compared with > > 1,2,3,4,5,6,7,8,9,10,11,12,13 > > Even though I prefer to specify vector lengths in bytes everywhere else > in the Linux user API (precisely to avoid the confusion you object to). > > This isn't finalised yet for kvmtool -- I need to rework the patches > and may not include it at all initially: kvmtool doesn't support > migration, which is the main usecase for being able to specify an exact > set of vector lengths AFAICT. > > Since this is otherwise only useful for migration, experimentation or > machine-driven configuration, a bitmask > > 0x1fff > > as some have suggested may well be a pragmatic alternative for kvmtool.
Just to be clear, I have suggested using bits (or bytes or megabytes depending on the exact value) only for the command-line-user-oriented sve-vl-max option, which would take a single value. For interoperation with the management layer, on the other hand, using a bitmap is perfectly fine, and whether the values encoded within are expressed in quadwords or whatever other format is largely irrelevant, so long as it it's properly documented of course. -- Andrea Bolognani / Red Hat / Virtualization
