Re: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> Jeremy Fitzhardinge <jeremy@xxxxxxxx> 03.09.09 19:29 >>>
>On 09/03/09 01:23, Jan Beulich wrote:
>> I don't think you can re-use the hypervisor updated version field here,
>> unless you add a protocol on how the two updaters avoid collision.
>> struct vcpu_time_info has a padding field, which might be designated
>> as guest-kernel-version.
>>   
>
>There's no padding.  It would be an extension of the pvclock ABI, which
>KVM also implements, so we'd need to make sure they can cope too.

struct pvclock_vcpu_time_info has a 'pad0' field afaics.

>We only need to worry about Xen preempting a kernel update rather than
>the other way around.  I think it ends up being very simple:
>
>void ctxtsw_update_pvclock(struct pvclock_vcpu_time_info *pvclock)
>{
>       BUG_ON(preemptible());  /* Switching VCPUs would be a disaster */
>
>       /*
>        * We just need to update version; if Xen did it behind our back, then
>        * that's OK with us.  We should never see an update-in-progress 
> because Xen
>        * will always completely update the pvclock structure before 
> rescheduling the
>        * VCPU, so version should always be even.  We don't care if Xen 
> updates the
>        * timing parameters here because we're not in the middle of a clock 
> read.
>        * Usermode might be in the middle of a read, but all it needs to see 
> is version
>        * changing to a new even number, even if this add gets preempted by 
> Xen in
>        * the middle.  There are no cross-PCPU writes going on, so we don't 
> need to
>        * worry about bus-level atomicity.
>        */
>       pvclock->version += 2;
>}

No, that won't work as-is, because you can't guarantee the compiler to
translate this to and add-with-memory-operand. While avoiding a bus
lock here indeed seems possible (as long as it is clear that user mode will
never be interested in reading other than the instance of the CPU it's
currently running on), you won't get away without inline assembly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel