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.
31 lines
532 B
Plaintext
31 lines
532 B
Plaintext
#
|
|
# This is a Xen VM config file for Qubes VM
|
|
# DO NOT EDIT - autogenerated by qubes tools
|
|
#
|
|
|
|
kernel="{kerneldir}/vmlinuz"
|
|
ramdisk="{kerneldir}/initramfs"
|
|
extra="ro nomodeset xencons=hvc rd_NO_PLYMOUTH 3 {kernelopts}"
|
|
root="/dev/mapper/dmroot"
|
|
tsc_mode = 2
|
|
|
|
memory = {mem}
|
|
maxmem = {maxmem}
|
|
name = "{name}"
|
|
|
|
disk = [ {rootdev}
|
|
{privatedev}
|
|
{volatiledev}
|
|
{otherdevs}
|
|
]
|
|
|
|
vif = [ {netdev} ]
|
|
|
|
pci = [ {pcidev} ]
|
|
|
|
vcpus = {vcpus}
|
|
|
|
on_poweroff = 'destroy'
|
|
on_reboot = 'destroy'
|
|
on_crash = 'destroy'
|