On Sat, Sep 03, 2022 at 06:52:20AM -0500, Scott Cheloha wrote:
> > 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.
static inline uint64_t
atomic_cas_64(volatile uint64_t *p, uint64_t o, uint64_t n)
{
return __sync_val_compare_and_swap(p, o, n);
}
Or md atomic.h files could have an equivalent.
Not possible on all 32-bit archs.
>
> We can't use FP registers in the kernel, no?
What do FP registers have to do with it?
>
> Am I missing some other avenue?
There is no rdtsc_lfence() on i386. Initial diff doesn't build.
