[PATCH 06/27] arm64/sve: System register and exception syndrome definitions

[alex.bennee@linaro.org (Alex Bennée)]

Dave Martin <Dave.Martin@arm.com> writes:

> On Mon, Aug 21, 2017 at 01:34:38PM +0100, Alex Benn?e wrote:
>>
>> Alex Benn?e <alex.bennee@linaro.org> writes:
>>
>> > Dave Martin <Dave.Martin@arm.com> writes:
>
> [...]
>
>> OK no I'm working directly from the unpacked ZIP file with the rest of
>> the details I think this should be:
>>
>>   #define SYS_ZCR_EL2			sys_reg(3, 5, 1, 2, 0)
>>
>> e.g. op1 = 101 / 5
>
> No, that's the encoding for ZCR_EL12.  Where did you get this from?

Sorry my mistake, -ETOOMANYBITTABLES....

>
> (This encoding follows the general pattern of the v8.1 Virtualization
> Host Extensions.)
>
> [...]
>
>> >> +#define ZCR_ELx_LEN_SHIFT	0
>> >> +#define ZCR_ELx_LEN_SIZE	9
>> >> +#define ZCR_ELx_LEN_MASK	0x1ff
>> >> +
>>
>> LEN should be 0/4/0xf
>>
>> LEN, bits [3:0]
>>
>> Constrains the scalable vector register length for EL1 and EL0 to
>> (LEN+1)x128 bits.
>
> The SVE supplement is not very explicit about the meaning of bits [8:4],
> but they are reserved to extend the LEN field in the future, in case
> that's ever needed for future architecture revisions.  I've aimed for
> Linux to cope with this.
>
> Basically bits [8:4] are read-as-zero, write-ignore today, but in
> the future some or all of them may be LEN field bits.
>
> In particular, this means that writing all bits [8:0] with 1 will
> configure the largest supported vector length, even on future
> architecture versions that may have a larger LEN field.

Ahh ok. It's not clear from the html and it is certainly implied in the
supplement (2.1.1) that the architectural max is:

  The size of every vector register is an IMPLEMENTATION DEFINED
  multiple of 128 bits, up to an architectural maximum of 2048 bits.

>
> It didn't seem useful to distinguish the two classes of bits here.

Maybe a comment clarifying would be useful then?

>
> Cheers
> ---Dave


--
Alex Benn?e