On Fri, May 06, 2016 at 02:36:17PM +0100, James Hogan wrote:
> This patchset is based on v4.6-rc4 and adds support for the optional
> extended ASIDs present since revision 3.5 of the MIPS32/MIPS64
> architecture, which extends the TLB ASIDs from 8 bits to 10 bits. These
> are known to be implemented in XLP and I6400 cores.
>
> Along the way a few cleanups are made, particularly for KVM which
> manipulates ASIDs from assembly code.
>
> Patch 6 lays most of the groundwork by abstracting asid masks so they
> can be variable, and patch 7 adds the actual support for extended ASIDs.
>
> Patches 1-5 do some preliminary clean up around ASID handling, and in
> KVM's locore.S to allow patch 7 to support extended ASIDs.
>
> The use of extended ASIDs can be observed by using the 'x' sysrq to dump
> TLB values, e.g. by repeatedly running this command:
> $(echo x > /proc/sysrq-trigger); dmesg -c | grep asid
Oh beloved ASIDs ...
Already PMC-Sierra's RM9000 / E9000 core had an extended ASID field, of
12 bits for 4096 ASID contexts. Afaics this was an extension derived
in-house back in the wild days before everything had to be sanctioned by
the architecture folks, so there is nothing in a config register to test
for it.
PMCS simply extended the ASID field to 12 bits; no of the EntryHi bits
which today would conflict doing so did exist back then.
Afair there was yet another core with such a non-standard extension of the
ASID field. R6000 and R8000 were weird, too.
Until commit f67e4ffc79905482c3b9b8c8dd65197bac7eb508 ("My proposal for
non-generic kernels:") we used to runtime patch the kernel (That's the
cowboy patch the commit message is refering to) to allow for variable
size of the ASID field and position of the ASID field in the EntryHi
register.
Ralf
