qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] target/arm: Clean up arm_cpu_vq_map_next_smaller asserts


From: Andrew Jones
Subject: Re: [PATCH] target/arm: Clean up arm_cpu_vq_map_next_smaller asserts
Date: Mon, 18 Nov 2019 08:51:55 +0100

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 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]