> On 08/26/09 08:42, Dan Magenheimer wrote:
> > But ARCHITECTURALLY does Xen consider write_tsc to be a no-op
> > for PV domains, or is this just a case that's never been
> > encountered before? In other words, if a future PV OS had a
> > good reason to write_tsc, would we implement it (and make
> > the necessary adjustments to Xen's usages of tsc) or just say,
> > sorry, not allowed? 
>
> 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. Indeed Linux itself
does. 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.
We've been lucky so far with allowing rdtsc to execute directly
in hardware, but we really do need to fix it properly.
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel