On Fri, Nov 15, 2019 at 06:45:51PM +0100, Richard Henderson wrote: > On 11/15/19 5:06 PM, Andrew Jones wrote: > >> bitnum = find_last_bit(cpu->sve_vq_map, vq - 1); > >> - return bitnum == vq - 1 ? 0 : bitnum + 1; > >> + > >> + /* We always have vq == 1 present in sve_vq_map. */ > > > > This is true with TCG and 99.9999% likely to be true with KVM... > > Eh? It's required by the spec that 128-bit vectors are always supported.
If some vendor messes things up with SVE in a way that makes it impossible to configure all should-be-supported lengths, then there's a chance KVM will simply not advertise the lengths that cannot be configured as a workaround. This may be quite unlikely, but when KVM is in use, IMO, it should be the sole authority on what lengths are available. Assuming lengths are available because the spec says so should work, but then 'hardware' is just another way to spell 'errata'... > > > > Maybe we should just remove this function and put the > > find_last_bit() call and all input/output validation directly in > > sve_zcr_get_valid_len() ? > > But that makes sense all on its own, so we don't do quite so much +1/-1 > faffing > about. > Thanks, drew
