[Xen-devel] RE: pvclock in userland (reprise)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> On 09/17/09 12:13, Nakajima, Jun wrote:
> > Maybe you can write a device driver in the guest that sets 
> up mapping against the (virtual) physical memory, then use 
> mmap() in the app?
> 
> Dan is trying to avoid making guest kernel changes, on the 
> grounds that
> waiting for enterprise distros to catch up would take too long.

Well, as I've said all along, a driver in a dynamically loadable
module is OK.  Whether sensible or not, customers don't seem to
care about that, they only care if you change the kernel bits
that gets loaded.

> Once you're making kernel changes then you can update the pvclock
> mechanism to use the xen clock algorithm, obviating the need for
> usermode ABI changes.

Is that working yet (fast vsyscall under Xen)? >:-)

> However, if its really the case that the tsc is guaranteed 
> synchronized,
> then the guest can determine that for itself by looking at 
> cpuid and/or
> /proc/cpuinfo (and presumably doing some sanity checking) and 
> then just
> directly use rdtsc, with no need to change either Xen or the kernel.

That's exactly what the app is doing when on bare metal.

But in virtual unless it gets some kind of notification on
migration (which would be cool, but would also require
kernel changes?), it can't determine the appropriate
scaling factor and offset, or that they need to change.
(The userland pvclock algorithm would need to keep
a version indicator just like the kernel pvclock does.)
So that's what the userland-accessible shared page
is needed for.

Dan

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