Re: [Xen-users] xen clocksource and TSC

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-11-06 at 15:21 -0700, David A. Van Arnem wrote:
> Hello all,
> 
> I'm working on manipulating the pv_soft_rdtsc() function in 
> arch/x86/time.c.  In a paravirtualized 64-bit Fedora 20 domain, with 
> tsc_mode="always_emulate" and "xen" as the current_clocksource, I find 
> that if the domain is running and then the TSC value written to EAX/EDX 
> is changed in pv_soft_rdtsc to be higher (faster) than normal, the 
> passage of wallclock time in the domain appears faster (expected).  
> However, if it is less than normal (slower), I would expect wallclock 
> time to appear slower, but instead the domain freezes and eventually the 
> watchdog timer is fired and it shuts down.  If I set the clocksource for 
> Fedora to TSC, I see the passage of time slow down for a varying amount 
> of time (sometimes seconds, sometimes minutes) but eventually again the 
> domain hangs and the watchdog timer fires.  There are no messages in xl 
> dmesg that indicate the domain is having problems (aside from the 
> watchdog messages), so I'm having trouble determining what is causing 
> this behavior.

Some kernels have a latch which prevents wallclock time going backwards
(IIRC it jsut reports the latest seen time until the clock catches back
up), could it be being tickled somehow by the changes you've made?

> I know that when the domain is created, there are time scales set to 
> convert TSC ticks to real-time, and vice-versa, for timekeeping 
> purposes.  I figured that if these scales remained the same, changing 
> the TSC values would change wallclock time in the domain.

AFAIK the TSC and wallclock time are not as closely related as you seem
to suggest, Xen provides them via different interfaces and even on
native I don't think the kernel treats them as the same thing. Messing
with the TSC doesn't have a direct affect on wallclock, I don't think.

AIUI the only relation between the two is that because reading the
wallclock time can be relatively slow the kernel tries (sometimes?) to
interpolate between readings based on the timer tick/tsc/etc.

I think the conversions to "real-time" you are looking at are actually
the scaling and offsetwhich are used to try and keep the guest's-view of
the TSC in some sort of consistent state as it roams around different
physical CPUs (or even migrates to other machines). They don't have any
particular relation to "real" or wallclock time nor are they converting
to that.

>  What else 
> might I need to consider, and/or, is this even possible on a running 
> domain?  Does changing the TSC value in pv_soft_rdtsc affect other parts 
> of the hypervisor (scheduling, etc) which might be affecting the 
> domain?  I know this may not be easy to answer, but any direction or 
> input would be very appreciated.

Messing with the TSC like this seems like a pretty odd thing to
want/need to do. I'd recommend taking a step back and explaining what
your actual end goal is -- perhaps someone can recommend a better way to
achieve your aim. Since it sounds like this is probably a development
project you might want to take that to the devel list instead.

Ian.


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users