[PATCH] arm64: Generate cpucaps.h

[Mark Brown]

On Tue, Sep 21, 2021 at 12:08:11PM -0600, dann frazier wrote:
> On Wed, Apr 28, 2021 at 01:12:31PM +0100, Mark Brown wrote:

> > This will result in a renumbering and reordering of the existing constants,
> > since they are all internal only the values should not be important. The
> > reordering will impact the order in which some steps in enumeration handle
> > features but the algorithm is not intended to depend on this and I haven't
> > seen any issues when testing.

> Unfortunately I believe I've hit a regression[*] due to such an
> ordering dependency. UNMAP_KERNEL_AT_EL0 currently needs to be
> processed after WORKAROUND_CAVIUM_27456. ThunderX systems are
> incompatible with KPTI, so unmap_kernel_at_el0() bails if
> WORKAROUND_CAVIUM_27456 is set. Because of the sorting,
> WORKAROUND_CAVIUM_27456 will not yet have been considered when
> unmap_kernel_at_el0() checks for it, so the kernel tries to
> run w/ KPTI - and quickly falls over.

> I've verified that reordering cpucaps to move WORKAROUND_CAVIUM_27456
> just above UNMAP_KERNEL_AT_EL0 restores the old behavior. I'm not sure
> of the right way to address this - perhaps unmap_kernel_at_el0() could
> check cavium_erratum_27456_cpus[] directly instead of keying on the
> ARM64_WORKAROUND_CAVIUM_27456 cap?

Ugh, right.  Another option would be to do something like rename to
CAVIUM_WORKAROUND_27456 which would be inconsistent naming and but would
sort things in a way that gets the checks to run in the order we're
relying on but either works for me.  Neither is great.

It'd be really good to get more coverage of the enterprise systems in
KernelCI or similar so we can catch issues like this more easily.
-------------- 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/20210921/748962b9/attachment.sig>