similar to: [PATCH] Fix lapic timer stop issue in deep C state

CPUIDLE: Avoid remnant LAPIC timer intr while force hpetbroadcast LAPIC will stop during C3, and resume to work after exit from C3. Considering below case: The LAPIC timer was programmed to expire after 1000us, but CPU enter C3 after 100us and exit C3 at 9xxus. 0us: reprogram_timer(1000us) 100us: entry C3, LAPIC timer stop 9xxus: exit C3 due to unexpected event, LAPIC timer continue running

Local APIC timer may stop at deep C state (C3/C4...) entry/exit. Initial HPET broadcast working in legacy replacing mode, broke RTC intr, so was bypassed. This patch add the logic that use platform timer (PIT) to reenable local APIC timer at C state entry/exit. Currently, only keep PIT enabled with 100Hz freq. The next step is trying to dynamically enable/disable PIT while needed, and give it

Hi, After c/s 18694 changed vHPET to vpt, for single HVM RHEL 5u1 guest idle case, our box will consume ~0.8W more power than before. The reason is two periodical vpts'' expires are hard to be aligned in the 50us soft timer SLOP. So we are considering a vpt specific enhancement which could try to just align periodical timers within vpt. A generic enhancement is to add a new interface

On Thu, 30 Sep 2010 14:02:34 +0800, gang.wei@intel.com wrote: > I am the original developer of HPET broadcast code. > > First of all, to disable HPET broadcast, no additional patch is required. > Please simply add option "cpuidle=off" or "max_cstate=1" at xen cmdline in > /boot/grub/grub.conf. > > Second, I noticed that the issue just occur on

ACPI C2 is quite possible mapped to CPU C3 or deeper state, so thinking from worst cases, enable C3 like entry/exit handling for C2 by default. Option ''lapic_timer_c2_ok'' can be used to select simple C2 entry/exit only if the user make sure that LAPIC tmr & TSC will not be stopped during C2. Signed-off-by: Wei Gang <gang.wei@intel.com>

x86:x2apic: Disable x2apic on x86-32 permanently x2apic initialization on x86_32 uses vcpu pointer before it is initialized. As x2apic is unlikely to be used on x86_32, this patch disables x2apic permanently on x86_32. It also asserts the sanity of vcpu pointer before dereference to prevent further misuse. Signed-off-by: Fengzhe Zhang <fengzhe.zhang@intel.com> diff -r 02c0af2bf280

Hi It seems that the Xen4.1''s HVM LAPIC clock for HVM fails to function normally, the guest OS cannot receive interrupts and Linux chooses to use PIT based TSC timer. Is there any change from Xen3.x with respect of this? Thanks - Zhefu _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Adjust handle_hpet_broadcast to let it run better before broadcast exit Since hpet_broadcast_exit has been moved after interrupt enabled in C3 case, so adjust the handler of hpet broadcast to adapt to this. Meanwhile, remove a freqently executed debug print line to simplify the serial output. Signed-off-by: Wei Gang <gang.wei@intel.com> diff -r 63317b6c3eab xen/arch/x86/hpet.c ---

This follows Linux commit 39fe05e58c5e448601ce46e6b03900d5bf31c4b0, noticing that all this setup is pointless when ARAT support is there, and knowing that on SLED11''s native kernel it has actually caused S3 resume issues. A question would be whether HPET legacy interrupts should be forced off in this case (rather than leaving whatever came from firmware). Signed-off-by: Jan Beulich

Hi, When using lapic as timer source the hypervisor delivers timer interrupts late. In the source xen/arch/x86/hvm/vpt.c function create_periodic_time creates a timer element with a "bonus" of 50% of the desired time until the interrupt: pt->scheduled = NOW() + period; /* * Offset LAPIC ticks from other timer ticks. Otherwise guests which use * LAPIC ticks for

Hi all, I have a following problem: - Remus network buffering doesn''t work. It seems to be because of no vif is reported by the function server.xend.domain on line 29 of /usr/local/lib/python2.7/dist-packages/xen/remus/vm.py (seen using pdb) : 27 if domid: 28 try: 29 self.dominfo = server.xend.domain(domid, ''all'') >

>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

What is the point of specifying "current" as the address to monitor? The memory location of interest really is irq_stat[cpu].__softirq_pending, and if that was used it would then also be possible to actually avoid sending IPIs when monitor/mwait are in use, as is being done on Linux. Jan _______________________________________________ Xen-devel mailing list

Hello gurus, I have two physical xen hosts and when I migrate a domU from one host to another, I get many of this error from domU kernel: clocksource/0: Time went backwards: delta=-3536123661 shadow=686019823475 offset=281887188 Sometimes domU time stalls and network stops working, but other times it gets working again. The two hosts are using different platform timer source:

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 =

This QEMU property is specific to x86/x86_64, so add it only on these architectures. --- lib/launch-direct.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/launch-direct.c b/lib/launch-direct.c index bc43dcea2..3b848165c 100644 --- a/lib/launch-direct.c +++ b/lib/launch-direct.c @@ -519,8 +519,10 @@ launch_direct (guestfs_h *g, void *datav, const char *arg) arg ("-rtc",

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

Due to recent changes in timer handling (specifically building hpet emulation on top of Xen system time and ensuring it is monotonic), I wonder if it now makes sense to: 1) change hvm default for hpet to 1 (was 0) 2) change hvm timer_mode default from 0 to 2 I encouraged adding the hvm hpet parameter and defaulting it to 0 because the virtual hpet was not reliable and many guests/versions

https://bugs.freedesktop.org/show_bug.cgi?id=68488 Priority: medium Bug ID: 68488 Assignee: nouveau at lists.freedesktop.org Summary: Lockup and reboot on T61 with nouveau driver/exa QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS: All Reporter: a9016009 at gmx.de

I have an error in my dmesg system log about hpet not correctly enabling: hpet_acpi_add: no address or irqs in _CRS The same kernel without Xen enables it fine: hpet0: at MMIO 0xfed00000 (virtual 0xffffffffff5fe000), IRQs 2, 8, 31 hpet0: 3 32-bit timers, 25000000 Hz hpet_resources: 0xfed00000 is busy Do I have to pass an additional boot option? (ACPI is already enabled) or is there