Re: Privilege Levels Below User

BGB wrote:

Though, there are some instructions which are currently allowed in user mode but which it could make sense to trap in some contexts, such as CPUID, or potentially just parts of CPUID, ...
 Say, for example, CPUID has several pieces of information available:
   CPU type and features;
   Microsecond timer (local);
   Clock cycle timer;
   Hardware RNG;
   ...
 In various contexts, it may be reasonable to want to trap and emulate some of these while still allowing others to be unhindered.

Yeah.

 Though, the time returned by the CPUID microsecond timer is not currently the same as the one given by "TK_GetTimeUS()", where the latter effectively gives a 64-bit value (conceptually) representing the number of microseconds since 1/1/1970; though with the kernel currently assuming that its build-time is the starting time for the clock (and none of the FPGA boards support a hardware clock, and one would need internet access to use NTP, ...).
 A 64-bit value in microseconds can express around +/- 300k years, which should be plenty.

Experience have shown that microsecond resolution is NOT good enough, i.e. GPS timing receivers can typically give you ~25 ns RMS accuracy for less than $100.
WinNT settled on 64-bit 100 ns ticks from 1600-01-01, that has turned out to be pretty good, but (see above) not quite good enough for all uses.
Modern Unix typically provides 64-bit time_t seconds and a (effectively) 30-bit ns field, so you can store them in a 96-bit container but I don't think anyone does that?
If you have a lot of such timestamps I would suggest you instead truncate the time_t seconds field to just the classic 32 bits and use windowing around the current (full resolution) time.

 A 64-bit value expressed in seconds could express values relative to the current age of the universe, but this is likely unnecessary for most purposes, and ability to express fractions of a second is likely more useful than the ability to express the age of the universe.

NTP only needs relative timestamps, so Dr Mills settled on 32-bit seconds (since 1900!) + 32-bit fractions, so NTP timestamps have roughly 0.25 ns resolution. The latter corresponds to 5 cm of fiber optic transmission delay.

  Granted, one could use a 128-bit value, and have both (and in picoseconds if they wanted). But, this would be overkill.
 Or, go extra overkill, and use 256 bits, to express the current age of the universe in Planck units...

:-)
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"