[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xen-4.1: PV domain hanging at startup, jiffies stopped

On 31/08/2011 21:49, "Marek Marczykowski" <marmarek@xxxxxxxxxxxx> wrote:

> xen_vcpuop_set_next_event schedules event by getting current time
> (xen_clocksource_read()) (*1) adding delta (expires-now) and programming
> event with VCPUOP_set_singleshot_timer hypercall. Then xen gets current
> time (*2) and in some rare cases this time is after expected timer
> expiration... Even after VCPUOP_set_singleshot_timer hypercal,
> xen_clocksource_read() reports time slightly in the past comparing to
> xen time (reported by NOW() macro).
> I think this is because "current" time is calculated different way in *1
> and *2. The *1 way is controlled by tsc_mode, which is described here:
> http://lxr.xensource.com/lxr/source/docs/misc/tscmode.txt. Default
> tsc_mode=0 is "smart" and I think because of that can be slightly before
> NOW() time. tsc_mode=2 looks almost the same as NOW() macro works.
> Is this reasoning correct?

They really ought to work out to the same thing. This will trivially be the
case with tsc_mode=2 because both guest and hypervisor will see the same
(real) values from RDTSC, and use the same offsets and sacle factors to turn
that into a current system time. When using emulated TSC in the guest
(tsc_mode=0,1) then the TSC values it sees, and the offsets and scale
factors it applies, are different. It is intended that it should result in
the same values being computed for NOW(), but I suppose something could be
going wrong there. By how much have you seen guest and hypervisor disagree?

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.