search for: get_s_tim

Hi Ian/Stefano: I changed over to the PV clock for hybrid liked we talked at the hackathon. I still have the hang in update_wall_time() after dom0 switches to xen as clocksource. The source of hang seems to be in xen stime_local_stamp in cpu_time that suddenly jumps to a large 64bit value. I''ve been chasing to figure where that happens, and why for the hybrid and not PV. It appears the

flight 18092 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/18092/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail pass in 18090 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass

...; (1LL << 31)) { + new_shift -= 1; + new_mult = new_mult << 1; + } + + t->tsc_scale.mul_frac = new_mult; + t->tsc_scale.shift = new_shift; + local_irq_disable(); + rdtscll(curr_tsc); + t->local_tsc_stamp = curr_tsc; + t->stime_local_stamp = get_s_time(); + t->stime_master_stamp = read_platform_stime(); + local_irq_enable(); + + platform_time_calibration(); +} + /* Set clock to <secs,usecs> after 00:00:00 UTC, 1 January, 1970. */ void do_settime(unsigned long secs, unsigned long nsecs, u64 system_time_base) { @@ -862,7 +897,...

The value of ACPI PM-Timer may be broken on save unless the timer mode is delay_for_missed_ticks. With other timer modes, vcpu->arch.hvm_vcpu.guest_time is always zero and the adjustment from its value is wrong. This patch fixes the saved value of ACPI PM-Timer: - don''t adjust the PM-Timer if vcpu->arch.hvm_vcpu.guest_time is zero. - consolidate calculations of PM-Timer to one

...id) { 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 +++ b/xen/include/xen/time.h Mon Mar 05 14:39:41 2012 +0800 @@ -34,6 +34,7 @@ typedef s64 s_time_t; s_time_t get_s_time(void); unsigned long get_localtime(struct domain *d); +uint64_t get_localtime_us(struct domain *d); struct tm { int tm_sec; /* seconds */

Hey, I''m experiencing strange problem: non-deterministic PV domain hang, only on some machines (with fast SSD drive). I''ve tried xen-4.1.0 and xen-4.1.1 with many kernels different kernels: VM: - 2.6.38.3 xenlinux based on SUSE package - vanilla 3.0.3 - vanilla 3.1 rc2 dom0: - 2.6.38.3 xenlinux based on SUSE package - vanilla 3.1 rc2 Result always the same: sometimes VM

This patch series implements SMP boot for arch/arm, as far as getting all CPUs up and running the idle loop. Changes from v1: - moved barriers out of loop in udelay() - dropped broken GIC change in favour of explanatory comment - made the increment of ready_cpus atomic (I couldn''t move the increment to before signalling the next CPU because the PT switch has to happen between

Hi all, With the new vm-tools we are trying to get top like capabilities going correctly. Currently we have a program vm-list that has some of this capability but is dependent on the cpu time given by libxc calls (xc_get_dom_info & xc_domain_get_cpu_usage). These two functions give you how much time (in nanoseconds, why is this not documented) the domain has been actively used. Approaches:

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

This round implements all of the review comments from V2 and all patches are now acked. Unless there are any objections I intend to apply later this morning. Ian.

First off, Apologies for the massive patch series... This series boots a 32-bit dom0 kernel to a command prompt on an ARMv8 (AArch64) model. The kernel is the same one as I am currently using with the 32 bit hypervisor I haven''t yet tried starting a guest or anything super advanced like that ;-). Also there is not real support for 64-bit domains at all, although in one or two places I