similar to: time went backwards

It seems that VCPU system time isn''t monotonic (using 3.0.4). It seems it might be correlated to when a VCPU is switched across real CPUs but I haven''t conclusively proved that. But e.g.: { old = { time = { version = 0x4ec pad0 = 0xe8e0 tsc_timestamp = 0x22cc8398b7194 system_time =

Could anyone summarize what the support status of cpu frequency changes is at present. I don''t seem to recall generic changes to the hpyervisor in that respect, but the linux tree has fairly extensive changes to the powernow-k8 driver (which would make sense to me only if all other cpufreq drivers are fully supported now, too). Thanks, Jan

Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2008-09-19/xen/arch/x86/platform_hypercall.c =================================================================== --- 2008-09-19.orig/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:02.000000000 +0200 +++ 2008-09-19/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:56.000000000 +0200 @@ -21,7 +21,7 @@ #include <xen/acpi.h>

>I''ve been seeing these pretty regularly on a single-socket dual-core Athlon >system for the last couple of months, and only on Friday finally found time >to start looking into these. Besides the messages above, I also see hangs >in about every other boot attempt but only if I do *not* use serial output >(which makes debugging a little harder), and never once initial boot

This fixes an actual bug (failure to exit from a function after an allocation failure), an inconsistency (not removing the cpufreq_dom list member upon failure), and a latent bug (not clearing the current governor upon governor initialization failure when there was no old one; latent because the only current code path leading to this situation frees the policy upon failure and hence the governor

it seems getting lost, and thus resend. Thanks, Kevin -----Original Message----- From: Tian, Kevin Sent: 2008年7月24日 8:39 To: ''Jan Beulich'' Cc: Liu, Jinsong; Keir Fraser; xen-devel@lists.xensource.com; mark.langsdorf@amd.com Subject: RE: [Xen-devel] cpufreq info propagation >From: Jan Beulich >Sent: 2008年7月23日 18:13 >> >>startup info is viable. But how

To my surprise, c/s 8888 enables CPU_FREQ for x86-64 rather than disabling it for i386. Did anyone at your end actually test that if enabled this at least builds properly now? Not to mention that of course this also should work... If I remember right, the main reason for posting a patch to disable it on 32-bits (similar to how it was on 64-bits before) was that there were some missing symbols, and

Another bundle of issues from Coverity triage. The first one is in x86/mm, and looks scarier than it is. The others are all in xen/drivers and AFAICT are pretty minor. Cheers, Tim.

This changeset reverts two previous corrections, for reasons that escape me. First, the domain map is again being confined to NR_CPUS, which I had submitted a patch to fix recently (yes, I realize the code has a TODO in there, but those really get forgotten about far too often). Second, the platform hypercall was reverted back to require all information to be passed to Xen in one chunk, whereas

These two patches provide the neccessary infrastructure changes for the processor-passthru driver [www.spinics.net/lists/linux-acpi/msg34655.html] to properly function. The first one is quite easy - we just modprobe the processor-passthru driver. The second allows it to work under AMD machines by exposing the PM RDMSR to dom0. It has been tested with 2.6.32 kernel as well to make sure it does

Currently, enable/disable turbo mode on AMD is broken: $ xenpm enable-turbo-mode 0 <-- works and proper CPU MSR bit is set $ xenpm enable-turbo-mode 1 <-- silently broken, MSR bit not set Since ->turbo is per policy, when user requests to enable/disable turbo mode, we need to set the bit in all of the ->cpus that this policy affects. --- xen/arch/x86/acpi/cpufreq/powernow.c | 2

Hi Folks, I want to calculate latency in transferring a buffer from domU kernel to dom0 kernel and vice versa. for that I need a time ''flavour'' (cycle counter time?) which reads the same in dom0 and domU. Could someone please let me know if cycle counter time is the right time to use? if not then which one (system time or wall clock time)? Also could someone please tell me how to

On a selection of boxes, ntpd running in Xen Dom0 reproducibly exhibits extermely high noise/jitter. Switching back to -default, non-xen kernel ntpd runs with very low jitter/noise. Question -- how can I ''tame'' ntpd noise & jitter when running in Dom0? Is the problem a config issue, or a bug? Already reported this downstream; everybody''s "stumped".

On a selection of boxes, ntpd running in Xen Dom0 reproducibly exhibits extermely high noise/jitter. Switching back to -default, non-xen kernel ntpd runs with very low jitter/noise. Question -- how can I ''tame'' ntpd noise & jitter when running in Dom0? Is the problem a config issue, or a bug? Already reported this downstream; everybody''s "stumped".

Enable cpufreq support in Xen for AMD Operton processors by: 1) Allowing the PowerNow! driver in dom0 to write to the PowerNow! MSRs. 2) Adding the cpufreq notifier chain to time-xen.c in dom0. On a frequency change, a platform hypercall is performed to scale the frequency multiplier in the hypervisor. 3) Adding a platform hypercall to the hypervisor the scale the frequency multiplier and reset

Hi, I recently subscribed to xen-users asking about a powernow-k8 problem, but in the meantime I am not sure if the users-list was the right place for it. So I decided to repeat my question here ;-) My current config is attached. --- snip --- Hi, I recently installed Xen on my AMD64 for my first time and so far, everything seems to work pretty fine. :-) I tried to enable cpu frequency

Now that I finally got around to update our sources, I had a closer look at those changes, and apart from stylistic issues on the Linux side (part of which I may have asked for, but the result was somewhat overdone so the code is hardly legible now - I''ve got a patch queued to streamline this a little) I find it rather odd (fragile) that the who-is-in-charge information gets propagated

Hi, while testing some APERF/MPERF semantics I discovered that this feature is enabled in Xen Dom0, but is not reliable. The Linux kernel''s scheduler uses this feature if it sees the CPUID bit, leading to costly RDMSR traps (a few 100,000s during a kernel compile) and bogus values due to VCPU migration during the measurement. The attached patch explicitly disables this CPU capability

Enable THERM_CONTROL MSR write for dom0 even cpufreq=xen Signed-off-by: Wei Gang <gang.wei@intel.com> diff -r bd683e0397b4 xen/arch/x86/traps.c --- a/xen/arch/x86/traps.c Tue Feb 17 22:29:38 2009 +0800 +++ b/xen/arch/x86/traps.c Wed Feb 25 11:23:01 2009 +0800 @@ -2187,10 +2187,17 @@ static int emulate_privileged_op(struct case MSR_IA32_MPERF: case MSR_IA32_APERF:

I have a high end IBM system with 4 HT CPUs, am running xen-unstable with only Dom0 active, and I get lots of "Timer ISR/n: Time went backwards" messages. This is a short segment from dmesg: Timer ISR/1: Time went backwards: -259000 4465110000000 9741000 4465120000000 Timer ISR/6: Time went backwards: -224000 4465110000000 9776000 4465120000000 Timer ISR/6: Time went backwards: -159000