> On 29 Mar 2023, at 11:32, Jan Beulich <jbeul...@suse.com> wrote:
>
> On 29.03.2023 12:01, Luca Fancellu wrote:
>>> On 28 Mar 2023, at 10:36, Jan Beulich <jbeul...@suse.com> wrote:
>>> Yet another question is whether both range checks (against
>>> SVE_VL_MAX_BITS and zcr_max_bits) are actually necessary / useful.
>>> Iirc 2048 is a hard upper bound, so zcr_max_bits being higher than
>>> that value should likely lead to not using SVE at all (if it doesn't
>>> already; didn't check).
>>
>> I think the check sve_vl_bits > zcr_max_bits is needed because from
>> sve_vl_bits = sve_decode_vl(config->arch.sve_vl); I can get values above the
>> maximum supported bits (zcr_max_bits), later on I will use the struct
>> arch_domain
>> field sve_vl to compute the size of the registers to be saved/restore
>>
>> Is there something I’ve missed from your comment?
>
> Hmm, I realize my earlier response may have been ambiguous: I didn't
> mean to question the presence of both checks individually. I merely
> meant to question whether in addition to the zcr_max_bits check you
> really also need the SVE_VL_MAX_BITS one.
Oh ok now I see what you mean, this check
if ( !is_vl_valid(sve_vl_bits) )
{
dprintk(XENLOG_INFO, "Unsupported SVE vector length (%u)\n”,
sve_vl_bits);
return -EINVAL;
}
Can be removed because if ( sve_vl_bits > zcr_max_bits ) is enough,
I agree and so is_vl_valid is not required anymore
>
> Jan
