> 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?

Reply via email to