Deutsch English Français Italiano |
<v464c4$73tb$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Terje Mathisen <terje.mathisen@tmsw.no> Newsgroups: comp.arch Subject: Re: Privilege Levels Below User Date: Mon, 10 Jun 2024 07:53:08 +0200 Organization: A noiseless patient Spider Lines: 81 Message-ID: <v464c4$73tb$1@dont-email.me> References: <jai66jd4ih4ejmek0abnl4gvg5td4obsqg@4ax.com> <Z9I8O.13$2JEf.11@fx14.iad> <5h%8O.4327$wDZ.776@fx48.iad> <v428v9$2o803$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Date: Mon, 10 Jun 2024 07:53:08 +0200 (CEST) Injection-Info: dont-email.me; posting-host="61a4720bc8db2ac0344820afeea0b6ea"; logging-data="233387"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1872yKBR/BQGwFOvCd00fd5e2Ff22R+hOj7EdtuyLPDQw==" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.18.2 Cancel-Lock: sha1:wLj57gVq9R5ojVa15o1KBPku0nc= In-Reply-To: <v428v9$2o803$1@dont-email.me> Bytes: 4007 BGB wrote: > Though, there are some instructions which are currently allowed in user= =20 > mode but which it could make sense to trap in some contexts, such as=20 > CPUID, or potentially just parts of CPUID, ... >=20 > Say, for example, CPUID has several pieces of information available: > =C2=A0 CPU type and features; > =C2=A0 Microsecond timer (local); > =C2=A0 Clock cycle timer; > =C2=A0 Hardware RNG; > =C2=A0 ... >=20 > In various contexts, it may be reasonable to want to trap and emulate=20 > some of these while still allowing others to be unhindered. Yeah. >=20 > Though, the time returned by the CPUID microsecond timer is not=20 > currently the same as the one given by "TK_GetTimeUS()", where the=20 > latter effectively gives a 64-bit value (conceptually) representing the= =20 > number of microseconds since 1/1/1970; though with the kernel currently= =20 > assuming that its build-time is the starting time for the clock (and=20 > none of the FPGA boards support a hardware clock, and one would need=20 > internet access to use NTP, ...). >=20 > A 64-bit value in microseconds can express around +/- 300k years, which= =20 > should be plenty. Experience have shown that microsecond resolution is NOT good enough,=20 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=20 out to be pretty good, but (see above) not quite good enough for all uses= =2E 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=20 truncate the time_t seconds field to just the classic 32 bits and use=20 windowing around the current (full resolution) time. >=20 > A 64-bit value expressed in seconds could express values relative to th= e=20 > current age of the universe, but this is likely unnecessary for most=20 > purposes, and ability to express fractions of a second is likely more=20 > useful than the ability to express the age of the universe. NTP only needs relative timestamps, so Dr Mills settled on 32-bit=20 seconds (since 1900!) + 32-bit fractions, so NTP timestamps have roughly = 0.25 ns resolution. The latter corresponds to 5 cm of fiber optic=20 transmission delay. >=20 >=20 > Granted, one could use a 128-bit value, and have both (and in=20 > picoseconds if they wanted). But, this would be overkill. >=20 > Or, go extra overkill, and use 256 bits, to express the current age of = > the universe in Planck units... :-) Terje --=20 - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"