951b2b0b69
The source of problem was clockevent_program_event returns -ETIME:
------------ kernel/time/clockevents.c:
/**
* clockevents_program_event - Reprogram the clock event device.
* @expires: absolute expiry time (monotonic clock)
*
* Returns 0 on success, -ETIME when the event is in the past.
*/
int clockevents_program_event(struct clock_event_device *dev, ktime_t
expires,
ktime_t now)
-------------
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 is almost the same as NOW() macro works.
After all tsc_mode=2 was default in xen-3.4.
|
||
|---|---|---|
| .. | ||
| aux-tools | ||
| clipboard_notifier | ||
| icons | ||
| init.d | ||
| misc | ||
| pm-utils | ||
| qmemman | ||
| qvm-core | ||
| qvm-tools | ||
| restore | ||
| vaio_fixes | ||
| qubes-cached.repo | ||
| qubes-guid.desktop | ||
| qubes-update-watch.desktop | ||
| qubes.repo | ||
| qubes.sudoers | ||
| qubes.SyncAppMenus | ||
| qubes.SyncAppMenus.policy | ||