> On Sep 3, 2022, at 07:37, Jonathan Gray <j...@jsg.id.au> wrote:
>
> 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.
Gotcha.
>> We can't use FP registers in the kernel, no?
>
> What do FP registers have to do with it?
I read someplace that using FP registers was
a quick and dirty way to take advantage of
the 64-bit-aligned atomic access guarantees
of the Pentium.
>> Am I missing some other avenue?
>
> There is no rdtsc_lfence() on i386. Initial diff doesn't build.
I will come back with a fuller patch in a bit.
