search for: sync_cmos_clock

While in the upstream kernel I''m unable to find any use of XENPF_settime (and the DOM0_SETTIME alias of it) at all, in the 2.6.18 tree (and the forward ports of it) the function gets used only when ntp_synced() returns true (and - that''s minor - when independent_wallclock is not set). It would however seem to me that this doesn''t cover the case where the host clock gets

...ic(); - setup_boot_APIC_clock(); + setup_boot_clock(); /* * Synchronize the TSC with the AP diff -r 77e4058e936b arch/i386/kernel/time.c --- a/arch/i386/kernel/time.c Thu Dec 14 16:40:14 2006 -0800 +++ b/arch/i386/kernel/time.c Thu Dec 14 16:40:16 2006 -0800 @@ -232,6 +232,7 @@ static void sync_cmos_clock(unsigned lon static void sync_cmos_clock(unsigned long dummy); static DEFINE_TIMER(sync_cmos_timer, sync_cmos_clock, 0, 0); +int no_sync_cmos_clock; static void sync_cmos_clock(unsigned long dummy) { @@ -275,7 +276,8 @@ static void sync_cmos_clock(unsigned lon void notify_arch_cmos_timer...

...ic(); - setup_boot_APIC_clock(); + setup_boot_clock(); /* * Synchronize the TSC with the AP diff -r 77e4058e936b arch/i386/kernel/time.c --- a/arch/i386/kernel/time.c Thu Dec 14 16:40:14 2006 -0800 +++ b/arch/i386/kernel/time.c Thu Dec 14 16:40:16 2006 -0800 @@ -232,6 +232,7 @@ static void sync_cmos_clock(unsigned lon static void sync_cmos_clock(unsigned long dummy); static DEFINE_TIMER(sync_cmos_timer, sync_cmos_clock, 0, 0); +int no_sync_cmos_clock; static void sync_cmos_clock(unsigned long dummy) { @@ -275,7 +276,8 @@ static void sync_cmos_clock(unsigned lon void notify_arch_cmos_timer...

...ic(); - setup_boot_APIC_clock(); + setup_boot_clock(); /* * Synchronize the TSC with the AP diff -r d1ec5a6e3e8c arch/i386/kernel/time.c --- a/arch/i386/kernel/time.c Tue Dec 12 13:53:09 2006 -0800 +++ b/arch/i386/kernel/time.c Tue Dec 12 13:53:15 2006 -0800 @@ -232,6 +232,7 @@ static void sync_cmos_clock(unsigned lon static void sync_cmos_clock(unsigned long dummy); static DEFINE_TIMER(sync_cmos_timer, sync_cmos_clock, 0, 0); +int no_sync_cmos_clock; static void sync_cmos_clock(unsigned long dummy) { @@ -275,7 +276,8 @@ static void sync_cmos_clock(unsigned lon void notify_arch_cmos_timer...

...ic(); - setup_boot_APIC_clock(); + setup_boot_clock(); /* * Synchronize the TSC with the AP diff -r d1ec5a6e3e8c arch/i386/kernel/time.c --- a/arch/i386/kernel/time.c Tue Dec 12 13:53:09 2006 -0800 +++ b/arch/i386/kernel/time.c Tue Dec 12 13:53:15 2006 -0800 @@ -232,6 +232,7 @@ static void sync_cmos_clock(unsigned lon static void sync_cmos_clock(unsigned long dummy); static DEFINE_TIMER(sync_cmos_timer, sync_cmos_clock, 0, 0); +int no_sync_cmos_clock; static void sync_cmos_clock(unsigned long dummy) { @@ -275,7 +276,8 @@ static void sync_cmos_clock(unsigned lon void notify_arch_cmos_timer...

...with a higher uptime, the system time in the guest advances by the difference between the two uptimes. I can think of a few possible fixes for this issue: 1) have system_time in the hypervisor start at unix epoch 0 (january 1st 1970) instead of at boot time - this may require some magic to sync_cmos_clock(), sync_xen_wallclock() and/or other functions so dom0 does not get too confused while changing the time during bootup 2) have time_init() and time_resume() calculate the hypervisor boot time from the shared_info ->wc_sec ->wc_nsec and the shared_info->per cpu vcpu_info->sy...

...==== --- linux-2.6.16-rc6.orig/arch/i386/kernel/time.c 2006-03-12 19:49:53.000000000 -0800 +++ linux-2.6.16-rc6/arch/i386/kernel/time.c 2006-03-12 19:57:42.000000000 -0800 @@ -329,6 +329,7 @@ unsigned long get_cmos_time(void) } EXPORT_SYMBOL(get_cmos_time); +int no_sync_cmos_timer; static void sync_cmos_clock(unsigned long dummy); static DEFINE_TIMER(sync_cmos_timer, sync_cmos_clock, 0, 0); @@ -375,7 +376,8 @@ static void sync_cmos_clock(unsigned lon void notify_arch_cmos_timer(void) { - mod_timer(&sync_cmos_timer, jiffies + 1); + if (!no_sync_cmos_timer) + mod_timer(&sync_cmos_timer, ji...

...==== --- linux-2.6.16-rc6.orig/arch/i386/kernel/time.c 2006-03-12 19:49:53.000000000 -0800 +++ linux-2.6.16-rc6/arch/i386/kernel/time.c 2006-03-12 19:57:42.000000000 -0800 @@ -329,6 +329,7 @@ unsigned long get_cmos_time(void) } EXPORT_SYMBOL(get_cmos_time); +int no_sync_cmos_timer; static void sync_cmos_clock(unsigned long dummy); static DEFINE_TIMER(sync_cmos_timer, sync_cmos_clock, 0, 0); @@ -375,7 +376,8 @@ static void sync_cmos_clock(unsigned lon void notify_arch_cmos_timer(void) { - mod_timer(&sync_cmos_timer, jiffies + 1); + if (!no_sync_cmos_timer) + mod_timer(&sync_cmos_timer, ji...

From: David Vrabel <david.vrabel@citrix.com> The high resolution timer code gets notified of step changes to the system time with clock_was_set() or clock_was_set_delayed() calls. If other parts of the kernel require similar notification there is no clear place to hook into. Add a clock_was_set atomic notifier chain (clock_was_set_notifier_list) and call this in place of clock_was_set().

Unlike full virtualization in which the virtual machine provides the same platform interface as running natively on the hardware, paravirtualization requires modification to the guest operating system to work with the platform interface provided by the hypervisor. Xen was designed with performance in mind. Calls to the hypervisor are minimized, batched if necessary, and non-critical codepaths

Unlike full virtualization in which the virtual machine provides the same platform interface as running natively on the hardware, paravirtualization requires modification to the guest operating system to work with the platform interface provided by the hypervisor. Xen was designed with performance in mind. Calls to the hypervisor are minimized, batched if necessary, and non-critical codepaths