Re: pv clock: kvm is incompatible with xen :-(

[Jeremy Fitzhardinge <jeremy@goop.org>]

Gerd Hoffmann wrote:
> Hmm, I somehow fail to see a case where it could be non-atomic ...
>
> get_time_values() copies a consistent snapshot, thus
> xen_clocksource_read() doesn't race against xen updating the fields.
> The snapshot is in a per-cpu variable, thus it doesn't race against
> other guest vcpus running get_time_values() at the same time.
>   

Xen could change the parameters in the instant after get_time_values().  
That change could be as a result of suspend-resume, so the parameters 
and the tsc could be wildly different.  It's definitely an edge-case, 
but it's easy enough to deal with.

>> There could be a loopless
>> __get_time_values() for use in this case, but given that it almost never
>> loops, I don't think its worthwhile.
>>     
>
> "in this case" ???  I'm confused.  There is only a single user of
> get_nsec_offset(), which is xen_clocksource_read() ...
>   

Sure, but get_time_values() has several other callers.  If 
xen_clocksource_read() had its own loop to make sure the read_tsc is 
atomic with respect to get_time_values, then get_time_values itself 
needn't loop.  But, given that it only loops in the very rare case that 
it races with Xen updating those parameters, it doesn't seem to make 
much difference either way.

    J

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone