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
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
