Hi Jason,
However, one thing that I've been thinking about is that the c0 random
register is actually kind of garbage. In my fuzzy decade-old memory of
MIPS, I believe the c0 random register starts at the maximum number of
TLB entries (16?), and then counts down cyclically, decrementing once
per CPU cycle. Is that right?
Yes, for the relevant CPUs the range is 63-8 << 8 for R3k machines and
47-0 (the lower bound can be higher if wired entries are used, which I
think we occasionally do) for R4k machines with a buggy CP0 counter. So
there are either 56 or up to 48 distinct CP0 Random register values.
If it is, there are some real pros and cons here to consider:
- Pro: decrementing each CPU cycle means pretty good granularity
- Con: wrapping at, like, 16 or something really is very limited, to
the point of being almost bad
Meanwhile, on systems without the c0 cycles counter, what is the
actual resolution of random_get_entropy_fallback()? Is this just
falling back to jiffies?
It depends on the exact system. Some have a 32-bit high-resolution
counter in the chipset (arch/mips/kernel/csrc-ioasic.c) giving like 25MHz
resolution, some have nothing but jiffies.
IF (a) the fallback is jiffies AND (b) c0 wraps at 16, then actually,
what would be really nice would be something like:
return (jiffies << 4) | read_c0_random();
It seems like that would give us something somewhat more ideal than
the status quo. Still crap, of course, but undoubtedly better.
It seems like a reasonable idea to me, but the details would have to be
sorted out, because where a chipset high-resolution counter is available
we want to factor it in, and otherwise we need to extract the right bits
from the CP0 Random register, either 13:8 for the R3k or 5:0 for the R4k.
Maciej
