Re: LSE Atomics

[Tobias Nygren <tnn%NetBSD.org@localhost>]

On Thu, 07 May 2020 13:04:55 +0100
Robert Swindells <rjs%fdy2.co.uk@localhost> wrote:

> 
> Martin Husemann <martin%duskware.de@localhost> wrote:
> >On Thu, May 07, 2020 at 01:13:21AM +0200, Tobias Nygren wrote:
> >> Fetch sysctl machdep.cpu0.cpu_id (see usr.sbin/cpuctl/arch/aarch64.c)
> >> Then test the ID_AA64ISAR0_EL1 register bits 23:20 for the value 0b0010.
> >
> >That doesn't sound safe (what if cpu0 and cpu$N disagree?)
> 
> Do we support any big.LITTLE systems ? If so, do the cpus have different
> instruction sets or just different speeds.
> 
> I was planning to commit a patch to nss that checks for crypto
> instructions, currently it just looks at cpu0. I suppose I can change
> this to AND together the results from all cpus.

The only one that comes to mind is the Rockchip RK3399. It implements
AES and SHA extensions on both clusters.

As other have pointed out, any system that implements ISA extensions on
only some cores would lose the second the scheduler decides to migrate
a process to a different cpu cluster so it needs clever hacks like
cluster affinity or migrating processes on SIGILL for instructions
where we know another CPU can handle it.

I don't think defaulting to the common denominator ISA is a good idea
because big.LITTLE is implemented for battery savings and for that you
do want to be on the core with hardware accelerated crypto when doing
crypto.

-Tobias