> On Sep 3, 2022, at 02:22, Jonathan Gray <j...@jsg.id.au> wrote: > > On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote: >> dv@ suggested coming to the list to request testing for the pvclock(4) >> driver. Attached is a patch that corrects several bugs. Most of >> these changes will only matter in the non-TSC_STABLE case on a >> multiprocessor VM. >> >> Ideally, nothing should break. >> >> - pvclock yields a 64-bit value. The BSD timecounter layer can only >> use the lower 32 bits, but internally we need to track the full >> 64-bit value to allow comparisons with the full value in the >> non-TSC_STABLE case. So make pvclock_lastcount a 64-bit quantity. >> >> - In pvclock_get_timecount(), move rdtsc() up into the lockless read >> loop to get a more accurate timestamp. >> >> - In pvclock_get_timecount(), use rdtsc_lfence(), not rdtsc(). >> >> - In pvclock_get_timecount(), check that our TSC value doesn't predate >> ti->ti_tsc_timestamp, otherwise we will produce an enormous value. >> >> - In pvclock_get_timecount(), update pvclock_lastcount in the >> non-TSC_STABLE case with more care. On amd64 we can do this with an >> atomic_cas_ulong(9) loop because u_long is 64 bits. On i386 we need >> to introduce a mutex to protect our comparison and read/write. > > i386 has cmpxchg8b, no need to disable interrupts > the ifdefs seem excessive
How do I make use of CMPXCHG8B on i386 in this context? atomic_cas_ulong(9) is a 32-bit CAS on i386. We can't use FP registers in the kernel, no? Am I missing some other avenue?