[bootwrapper PATCH v2 09/13] aarch64: move the bulk of EL3 initialization to C

[Mark Brown]

On Mon, Jan 17, 2022 at 06:31:17PM +0000, Andre Przywara wrote:
> Mark Rutland <mark.rutland at arm.com> wrote:
> > On Mon, Jan 17, 2022 at 02:31:04PM +0000, Andre Przywara wrote:
> > > On Fri, 14 Jan 2022 10:56:49 +0000
> > > Mark Rutland <mark.rutland at arm.com> wrote:

[Out of office this week so replies might be intermittent]

> > > And apart from bit 0 missing from it (as noted above), the existing
> > > code writes 0x1ff into that register, presumable to cover future
> > > vector length extensions beyond 2048 bits (which those RAZ/WI fields
> > > in bits[8:4] seem to suggest).  

> > Hmm... I went and found the SVE supplement and I can't see any rationale
> > for what SW *should* do, nor can I find a description of the register
> > (that seems to have been factored into some XML files I can't convince
> > anything to load on my machine).

...

> > TBH, I'm not sure. In the absence of some documented guidance I'd prefer
> > to go with 0xf, but given we already use 0x1ff, I want to dig into this
> > a bit more.

I'm fairly sure I've seen some explicit discussion of this lurking
somewhere, though I couldn't tell you where - DDI0584 A.i doesn't spell
out the enumeration algorithm unfortunately AFAICT.  The theory is that
the extra bits are reserved for any future extension of the vector
length if needed since it'd be inconvenient to have to split the vector
length field up.

> My impression was that this "[8:4] = RAZ/WI" compared to the "[63:9] =
> RES0" fields suggests this is for a potential extension, but I guess there
> would be more changes needed if SVE ever goes beyond 2048. So chances are
> high we need to adopt the code then anyway, and fixing the number then is
> the least of our problems.

> So I feel we should stick to what's explicitly documented, and put 0xf in
> there.

We shouldn't need particularly many changes if the size of the field
ever gets raised, with everything being dynamically sized already and
the existing code starting off setting the WI bits to 1 the updates that
are needed should just be on input validation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220118/e7004054/attachment.sig>