> On 29 Mar 2023, at 11:32, Jan Beulich wrote:
>
> On 29.03.2023 12:01, Luca Fancellu wrote:
>>> On 28 Mar 2023, at 10:36, Jan Beulich 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
On 29.03.2023 12:01, Luca Fancellu wrote:
>> On 28 Mar 2023, at 10:36, Jan Beulich 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
>> tha
Hi Jan,
Thank you for your review, very appreciated,
> On 28 Mar 2023, at 10:36, Jan Beulich wrote:
>
> On 27.03.2023 12:59, Luca Fancellu wrote:
>> @@ -43,8 +44,16 @@ register_t compute_max_zcr(void)
>> }
>>
>> /* Takes a vector length in bits and returns the ZCR_ELx encoding */
>> -register_
On 27.03.2023 12:59, Luca Fancellu wrote:
> @@ -43,8 +44,16 @@ register_t compute_max_zcr(void)
> }
>
> /* Takes a vector length in bits and returns the ZCR_ELx encoding */
> -register_t vl_to_zcr(uint16_t vl)
> +register_t vl_to_zcr(unsigned int vl)
> {
> ASSERT(vl > 0);
> return ((
Add sve_vl field to arch_domain and xen_arch_domainconfig struct,
to allow the domain to have an information about the SVE feature
and the number of SVE register bits that are allowed for this
domain.
sve_vl field is the vector length in bits divided by 128, this
allows to use less space in the st
