On Mon, Jan 17, 2022 at 06:31:17PM +0000, Andre Przywara wrote: > Mark Rutland 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 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.