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

[Alex Bennée]

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

> On Mon, Aug 21, 2017 at 03:50:32PM +0100, Alex Bennée wrote:
>> Dave Martin <Dave.Martin at arm.com> writes:
>> > On Mon, Aug 21, 2017 at 01:34:38PM +0100, Alex Bennée wrote:
>
> [...]
>
>> >> > Dave Martin <Dave.Martin at arm.com> writes:
>
> [...]
>
>> >> >> +#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?
>
> OK, I think I can say something like:
>
> /*
>  * The ZCR_ELx_LEN_* definitions intentionally include bits [8:4]
>  * which are reserved by the SVE architecture for future expansion of
>  * the LEN field, with compatible semantics.
>  */
>
> Any good?

Works for me ;-)

>
> Cheers
> ---Dave


--
Alex Bennée