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

From: Mark Rutland <mark.rutland@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Andre Przywara <andre.przywara@arm.com>,
	linux-arm-kernel@lists.infradead.org, Jaxson.Han@arm.com,
	robin.murphy@arm.com, vladimir.murzin@arm.com, Wei.Chen@arm.com
Subject: Re: [bootwrapper PATCH v2 09/13] aarch64: move the bulk of EL3 initialization to C
Date: Wed, 19 Jan 2022 15:22:09 +0000	[thread overview]
Message-ID: <20220119152209.GA43919@C02TD0UTHF1T.local> (raw)
In-Reply-To: <YebvxEI+cnYMDu1j@sirena.org.uk>

On Tue, Jan 18, 2022 at 04:50:12PM +0000, Mark Brown wrote:
> On Mon, Jan 17, 2022 at 06:31:17PM +0000, Andre Przywara wrote:
> > Mark Rutland <mark.rutland@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@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.

Taking a look around, TF-A programs 0xf, and for consistency I think
it'd be clearer to only program the currently-allocated LEN bits.

I'll spin a preparatory patch reducing ZCR_EL3_LEN_MASK to 0xf (and
renaming that to ZCR_EL3_LEN_MAX).

If we need to grow it in future it should be trivial to do so.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel