Re: [PATCH 002/120] MIPS: R5900: Trap the RDHWR instruction as an SQ address exception

["Maciej W. Rozycki" <macro@linux-mips.org>]

On Sat, 12 Dec 2020, Fredrik Noring wrote:

> >  The use of RDHWR, actual or emulated, is a part of the MIPS TLS psABI, 
> > see: <https://www.linux-mips.org/wiki/NPTL>, in particular starting from: 
> > <https://www.linux-mips.org/wiki/NPTL#Design_Choices> and throughout (the 
> > expired certificate of the web site is a known issue, but there is 
> > currently no way to get it fixed as nobody knows where Ralf Baechle has 
> > gone).
> 
> Can the site be wrapped up and published elsewhere?

 Well if someone does that, sure!  I guess archive.org will have it too.

> >  This of course disagrees with what Fredrik wrote in the quotation above, 
> > as it's the last page rather than the zeroth that is accessed, but the net 
> > effect is the same, or even better.
> 
> The first page could be mapped by the application itself, but what about

 It doesn't matter given that `rdhwr $3, $29' maps to an R5900 instruction 
that does not access it.

> RDHWR registers $0-$3 having mnemonics CPUNum, SYNC1_Step, CC and CCRes[1],
> or in Linux
> 
> /* RDHWR register numbers */
> #define MIPS_HWR_CPUNUM		0	/* CPU number */
> #define MIPS_HWR_SYNCISTEP	1	/* SYNCI step size */
> #define MIPS_HWR_CC		2	/* Cycle counter */
> #define MIPS_HWR_CCRES		3	/* Cycle counter resolution */
> #define MIPS_HWR_ULR		29	/* UserLocal */
> #define MIPS_HWR_IMPL1		30	/* Implementation dependent */
> #define MIPS_HWR_IMPL2		31	/* Implementation dependent */
> 
> in arch/mips/include/asm/mipsregs.h? They land on the first page, no?

 Unlike TLS pointer access, specifically using $3 as rt, which has been 
made a part of the Linux ABI, they're not supposed to be referred with 
pre-R2 code.  After all RDHWR was only introduced with R2.

 Indeed there's emulation code in the kernel for those encodings even with 
pre-R2 hardware, but it is not guaranteed to give sensible results, and 
given the circumstances I'm not sure what it really is for, e.g. what is 
SYNCI_Step for with processors that do not implement SYNCI?  The cycle 
counter register may be absent too, so even emulated accesses will return 
rubbish; gettimeofday(2) is the standard interface.

 So I think we can safely ignore them, just as we can any ULR access with 
rt != $3.  Unlike standardised TLS pointer accesses such instructions 
won't appear in compiler-generated code and whoever uses them in handcoded 
assembly or otherwise generated machine code will have to make sure they 
make sense for their application (yes, there's rubbish code out there, 
e.g. Firefox has a JIT that unconditionally produces MIPS R2 code even if 
the piece of software has been compiled for an older ISA revision, and 
having not verified that the CPU it runs on actually supports the R2 ISA, 
but that's just the usual imperfection of the world; you just can't fix it 
all).

  Maciej