search for: wc_sec

...hung, When we take those steps 1, save PV domain 2, change system time of PV domain back 3, restore a PV domain or 1, migrate a PV domain from Machine A to Machine B 2, the system time of Machine B is slower than Machine A. the problem is wc_sec will be change when system-time chanaged in dom0 or restore in a slower-system-time machine, but when restoring, xen don''t restore the wc_sec of share_info from xenstore and use native one. So guest os will hang. this patch will work for this issue. Thanks -- Song Wei diff -r a5ed0dbc...

...g@novell.com] Sent: Thursday, November 27, 2008 11:20 AM To: keir.fraser@eu.citrix.com; Tian, Kevin; xen-devel@lists.xensource.com Subject: 答复： Re: [Xen-devel] when timer go back in dom0 save and restore ormigrate, PV domain hung Hi, yes, there is a patch before to fix problem wc_sec/wc_nsec in xc_domain_restore.c, but it still missed something. If constucting dom0 or restoring of a PV dom. Guest os will read the local wc_sec from xen as it base time.wc_sec is initialized with CMOS data. There were some case which wc_sec will be changed. One is that go back dom0'...

While digging through the time code, I found something very strange in do_settime: x = (secs * 1000000000ULL) + (u64)nsecs - system_time_base; y = do_div(x, 1000000000); spin_lock(&wc_lock); wc_sec = _wc_sec = (u32)x; wc_nsec = _wc_nsec = (u32)y; spin_unlock(&wc_lock); The value "x" appears to be the number of nanoseconds, while the value "y" is the value in seconds. The assignments to wc_sec and wc_nsec seem backwards, though... I hope I''ve over...

...ead 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->system_time -- if the host boot time changes (by more than a second?) adjust some local offset that we add into get_nsec_offset() and get_usec_offset() to always adjust the time right 3) get_time_values_from_xen() and __update_...

...set_timer(&t->calibration_timer, NOW() + EPOCH); +} + +void destroy_percpu_time(void) +{ + kill_timer(&this_cpu(cpu_time).calibration_timer); } /* Late init function (after all CPUs are booted). */ @@ -926,6 +1013,56 @@ unsigned long get_localtime(struct domai { return wc_sec + (wc_nsec + NOW()) / 1000000000ULL + d->time_offset_seconds; +} + +/* timer suspend/resume */ +static u64 sleep_start; +int time_suspend(void) +{ + sleep_start = get_cmos_time(); + + /* Better to cancel calibration timer for accuracy */ + destroy_percpu_time(); + + if (cur...

It''s come to our attention, that the time gets screwed up when set between EPOCH and EPOCH + uptime. This may not seem important (because we don''t live in the 70s anymore) but it makes LTP fail. LTP has a date test that checks what happens when set to EPOCH + 100 secs + 100 nsecs, and makes sure that it gets a proper result. The following patches helps xen handle the case

Respin of the paravirt clock patch series. On the host side the kvm paravirt clock is made compatible with the xen clock. On the guest side some xen code has been factored out into a separate source file shared by both kvm and xen clock implementations. This time it should work ok for kvm smp guests ;) cheers, Gerd

Respin of the paravirt clock patch series. On the host side the kvm paravirt clock is made compatible with the xen clock. On the guest side some xen code has been factored out into a separate source file shared by both kvm and xen clock implementations. This time it should work ok for kvm smp guests ;) cheers, Gerd

paravirt clock source patches, next round, with a bunch of changes in the host code according to Avi's review comments and some minor code tweaks. cheers, Gerd

paravirt clock source patches, next round, with a bunch of changes in the host code according to Avi's review comments and some minor code tweaks. cheers, Gerd

...0 +++ b/xen/arch/x86/time.c Mon Mar 05 14:39:41 2012 +0800 @@ -1601,6 +1601,13 @@ unsigned long get_localtime(struct domai + d->time_offset_seconds; } +/* Return millisecs after 00:00:00 localtime, 1 January, 1970. */ +uint64_t get_localtime_us(struct domain *d) +{ + return ((wc_sec + d->time_offset_seconds) * 1000000000ULL + + wc_nsec + NOW()) / 1000UL; +} + unsigned long get_sec(void) { return wc_sec + (wc_nsec + NOW()) / 1000000000ULL; diff -r 47cb862a07c2 -r edc35b026509 xen/include/xen/time.h --- a/xen/include/xen/time.h Mon Mar 05 14:39:07 2012 +0800...

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. Some minor tweaks after super-fast review by Jeremy. The queue is on top of the kvm git tree. The first two patches should have no kvm dependencies and should apply to linus tree just fine. cheers, Gerd

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. Some minor tweaks after super-fast review by Jeremy. The queue is on top of the kvm git tree. The first two patches should have no kvm dependencies and should apply to linus tree just fine. cheers, Gerd

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. cheers, Gerd

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. cheers, Gerd

The paravirtualized guests are offered wallclock time referenced to UTC only, while fully virtualized guests are given the option via the config file (localtime parameter) of starting with UTC time or local time. What would it take to optionally provide localtime to the paravirtualized guests as well? For a guest that launches assuming localtime as its time basis, then later deriving UTC from it

...cal_tsc_stamp ) __update_vcpu_system_time(v); } @@ -698,10 +698,10 @@ void update_vcpu_system_time(struct vcpu void update_domain_wallclock_time(struct domain *d) { spin_lock(&wc_lock); - version_update_begin(&d->shared_info->wc_version); - d->shared_info->wc_sec = wc_sec + d->time_offset_seconds; - d->shared_info->wc_nsec = wc_nsec; - version_update_end(&d->shared_info->wc_version); + version_update_begin(&shared_info(d, wc_version)); + shared_info(d, wc_sec) = wc_sec + d->time_offset_seconds; + shared_info(d, wc_...

Doing some janitorial (you cleaning the flooded toilets and such) work today. I have come across this line of code that really I''m not sure what the intent was..in xen/include/sched.h #define hypercall_preempt_check() (unlikely( \ softirq_pending(smp_processor_id()) | \ (!!current->vcpu_info->evtchn_upcall_pending & \

...d long evtchn_mask[sizeof(unsigned long) * 8]; + + /* + * Wallclock time: updated only by control software. Guests should base + * their gettimeofday() syscall on this wallclock-base value. + */ + uint32_t wc_version; /* Version counter: see vcpu_time_info_t. */ + uint32_t wc_sec; /* Secs 00:00:00 UTC, Jan 1, 1970. */ + uint32_t wc_nsec; /* Nsecs 00:00:00 UTC, Jan 1, 1970. */ + + struct arch_shared_info arch; + +}; +typedef struct shared_info shared_info_t; + +/* + * Start-of-day memory layout for the initial domain (DOM0): + * 1. The domain is st...

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