[PATCH 0/3] arm64: errata: remove BF16 HWCAP due to incorrect result on Cortex-A510

[Robin Murphy]

On 2022-09-15 14:39, James Morse wrote:
> Hi Robin,
> 
> On 09/09/2022 19:29, Robin Murphy wrote:
>> On 2022-09-09 17:59, James Morse wrote:
>>> Cortex-A510 has an erratum where the BFMMLA or VMMLA instructions might
>>> produce the incorrect result. This only happens if two Cortex-A510 CPUs
>>> are configured by the SoC manafacturer in a particular way to share some
>>> hardware, and are using it at the same time. It isn't possible for linux
>>> to know how the CPUs were configured, so the only option is to disable
>>> the BF16 feature for all Cortex-A510 CPUs.
> 
>> Hmm, the TRM doesn't seem to describe any obvious restrictions on accessing IMP_CPUCFR_EL1
>> - is there some other nefarious secret at play there?
> 
> HCR_EL2.TIDCP.

Aha, indeed I should have looked more closely at the pseudocode.

> KVM traps all IMP_* registers from EL1, and has no ability to emulate them.
> For an erratum workaround at EL1, touching an imp-def register is the wrong thing to do.

Well, there's no real reason we couldn't make KVM handle this case, but 
that doesn't help if we're booted at EL1 under some other hypervisor, so 
in general I concur.

> We could add some discovery API with firmware to determine if the part is affected, but I
> think that is overkill for this. I'm pretty sure affected Cortex-A510 silicon is only in
> mobile phones, which can have the Kconfig option disabled if the target platform isn't
> affected. (Even with GKI, I assume things don't run one kernel image in the same way
> distros do)

I suppose it wouldn't take *too* much to check this in init_el2 and 
stash a "no actually it's fine" flag for later, but whether even that's 
worth it depends on how big the impact of losing BF16 on unaffected 
configurations actually is (which I have no idea about). If someone does 
care then that can always be added later, so that's good enough for me!

Cheers,
Robin.