[Xen-devel] pvclock in userland (reprise)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Some offlist email with the Intel team may have
solved the thorniest issues for my earlier proposal
explained here:

http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01209.html

The key showstoppers for this were that the pvclock
mechanism as used by a guest kernel depends on
knowing the vcpu number and fetching the proper
adjustment values which differ depending on the
vcpu.  AND even if you could get the vcpu number
and proper adjustment values, there is no way
to ensure that a context switch doesn't occur
right in the middle of the pvclock computation
that changes what values must be used.

Jun pointed out that on the majority of Intel
processors and Intel-based systems that Xen runs
on today AND the VAST majority of new Intel
and AMD systems being shipped that Xen will run on
tomorrow, TSC is "reliable", meaning it is synchronized
within a reasonable error range across all processors.

So suppose there is a single page for all processors
that contains a flag field: "TSC_is_reliable".
If TSC_is_reliable is set (by Xen), then the app can
safely use the remaining fields to compute the pvclock
algorithm.  If it is NOT set, the app must use
a much slower system call (or a somewhat-slower
yet-to-be-designed userland hypercall).

A remaining hard problem is that this single
"userland-accessible shared page" must be somehow
made available to apps (I suggested a rdmsr emulated
by Xen so that it works in userland) and must be
mapped into the app address space without kernel
changes.  I think someone (Keir?) suggested this
problem was solveable before we got sidetracked
on the need-vcpu-number-in-userland problem.

Comments?

Thanks,
Dan

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