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
