Re: [Xen-devel] write_tsc in a PV domain?

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

On 08/26/09 13:23, Dan Magenheimer wrote:
>> You can think of it this way: a Xen PV VCPU has no tsc. There is a
>> register that can be read with "rdtsc", but that're purely 
>> part of Xen's
>> time ABI and is not independently useful.  The ABI includes 
>> no notion of
>> writing to that register.  Usermode code can execute "rdtsc", but
>> without access to the rest of the time parameters it just returns some
>> undefined bits with no relationship to time.
>>     
> While I think I understand entirely why you would want to
> think of it that way, there's thousands (millions?) of applications
> out there that would beg to differ.  They DO assume that
> rdtsc bears "some" relationship to time.

They are wrong.  Linux doesn't offer the tsc to usermode for its use. 
The closest it gets is vgettimeofday, which we could implement better.

>   Indeed Linux itself
> does. 

A pv linux guest doesn't have a TSC in the same way that it doesn't have
a TSS or any number of other CPU features.  It would be a grave error
for the kernel to use a tsc-based clocksource rather than the Xen pv
clocksource.  A Xen PV VCPU bears a passing resemblance to an Intel x86
CPU, but should not be confused with one.

>  Exactly what that relationship to time is defined to be is
> open to debate, and whether Xen supports whatever relationship
> is defined is also debatable (especially in the presence of
> migration).  But defining rdtsc as returning random bits
> is not an acceptable solution for Xen.  Dom0 won't even
> boot if rdtsc returns random bits so Xen must already be
> guaranteeing that rdtsc has "some" relationship to time.
>   

No, it really doesn't.  It provides a PV clock, which includes "rdtsc"
as part of its ABI.  It is not a general tsc.  You can't meaningfully
execute "rdtsc" without also being (indirectly) aware of what pcpu its
running on and applying the appropriate corrections to turn it into
system monotonic time.  Executing rdtsc willy-nilly gets you useless
results; fortunately no PV Xen kernel does that.

> We've been lucky so far with allowing rdtsc to execute directly
> in hardware, but we really do need to fix it properly.
No, that's false.  The current Xen time model works fine for all guests
using it correctly.

Emulating rdtsc for hvm guests is another question entirely.

> But since applications cannot WRITE to tsc and Xen has some
> control over the OS->Xen PV API, it might be safe to define that
> write_tsc is a no-op.
>   

No, write_tsc is meaningless, and anyone trying to execute it is not
even wrong.

    J

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