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

[Dave Martin]

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?

Cheers
---Dave