similar to: [PATCH 0/2] CPUIDLE: fixings for multiple C3 & C2 LAPIC stop

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>

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

Without this patch, while running on platforms on which the deepest C-state is C2, acpi_processor_idle fns will call into NULL function. BTW, made a little enhancement for keyhandler print-out to make it more readable. Signed-off-by: Wei Gang <gang.wei@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Current xen-linux (2.6.18) not include support for Cx MWAIT entry method. Back port from latest Linux kernel (already there since 2.6.23). Without this patch, _CST method couldn''t get C states with FFH address space type. Signed-off-by: Wei Gang <gang.wei@intel.com> Jimmy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Local APIC timer may stop at deep C state (C3/C4...) entry/exit. this patch add the logic that use platform timer (HPET) to reenable local APIC timer at C state entry/exit. Signed-off-by: Wei Gang <gang.wei@intel.com> Signed-off-by: Yu Ke <ke.yu@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

cpuidle: Fix for timer_deadline==0 case After the scheduler timer became suspended before entering cpu idle state, the percpu timer_deadline is possible to be 0, i.e. no soft timer in the queue. This case will cause unexpected large residency percentage in C1 for the purely idle cpu. The fix is if timer_deadline == 0, skip most hpet broadcast enter logic because no broadcast is needed for this

This patchset enable support for C1 mwait entry. [PATCH 1/3] dom0-C1-FFH.patch. It gets C1 information from ACPI table and pass it to Xen. [PATCH 2/3] add-idx-field.patch. This patch adds an idx field in the ''struct acpi_processor_cx''. It can simplify some coding lines. [PATCH 3/3] xen-C1-FFH.patch. It adds support for C1 FFH (mwait) entry. Meanwhile add timing for C1. The

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

In virtualized environment the APIC timer calibration could go wrong when the host is overcommitted or the guest is running nested, this would result in the APIC timers operating at an incorrect frequency. Since VMware supports a mechanism to retrieve the local APIC frequency we can ask the hypervisor for it and skip this APIC calibration loop. Signed-off-by: Renat Valiullin <rvaliullin at

In virtualized environment the APIC timer calibration could go wrong when the host is overcommitted or the guest is running nested, this would result in the APIC timers operating at an incorrect frequency. Since VMware supports a mechanism to retrieve the local APIC frequency we can ask the hypervisor for it and skip this APIC calibration loop. Signed-off-by: Renat Valiullin <rvaliullin at

On Wed, 19 Jul 2017 16:48:23 +0800 (CST) <wang.yi59@zte.com.cn> wrote: > >* wang.yi59@zte.com.cn (wang.yi59@zte.com.cn) wrote: > > > >> Hi Eduardo, > > >> > > >> Thank you for your reply! > > >> > > >> >On Mon, Jul 17, 2017 at 09:49:37PM -0400, Yi Wang wrote: > > >> > >

Hi, I have a system based on a Supermicro X8DTH-i motherboard and a Xeon E5506 CPU. It was previously running Debian lenny with xen-hypervisor-3.2-1-amd64 (3.2.1-2) / linux-image-2.6.26-2-xen-amd64 (2.6.26-29) without incident. I upgraded it to Debian squeeze, with xen-hypervisor-4.0-amd64 (4.0.1-4) / linux-image-2.6.32-5-xen-amd64 (2.6.32-45) and now it does not complete a boot of the dom0

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, I'm geting this message from virt-manager. Server: SuperMicro X8SIL with INTEL X3440 Here is my logs /var/log/dmesg: Bootdata ok (command line is ro root=/dev/md2) Linux version 2.6.18-194.3.1.el5xen (mockbuild at builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu May 13 13:49:53 EDT 2010 BIOS-provided physical RAM map: Xen: 0000000000000000 -

Hey, I have a nighly build/test system that boots various machines with upstream Linux and randomly selects Xen 4.1, Xen 4.2, Xen 4.3 and unstable. After a bit of digging I found out that Xen 4.2 ''xl'' (but not ''xm'') has some badness in it. When "migrating" (''xl'' save followed by ''xl'' restore'') the PVHVM

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

(copying xen-devel, full logs are at bugs.debian.org/748052, this is Debian Jessie, Xen 4.3.0 and Linux 3.13 Mike also reported that Debian Wheezy Xen 4.1.4 didn't work either, not clear which kernel that was with though, Wheezy's 3.2 or Jessie's 3.13) On Thu, 2014-05-15 at 10:11 -0700, Mike Egglestone wrote: > Here are some results with (now) the latest BIOS version 41. (was >

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

Hi, I have a problem booting the Xen hypervisor on my brand new Lenovo Thinkpad T400 2765D2G (Core2 Duo P8600 CPU, 2.40GHz. 4GB RAM). I''m running Debian 5.0 (Lenny) and I use the Debian-provided xen-hypervisor-3.2-1-amd64 package. The Dom0 kernel seems to be the Xen patches ported to a 2.6.26 kernel: linux-image-2.6.26-1-xen-amd64 I can boot the hypervisor only very unrealiably: Out of

Package: xen-hypervisor-3.2-1-amd64 Version: 3.2.1-2 Severity: important The Xen hypervisor very unreliably boots on my 4GB Lenovo Thinkpad T400 2765D2G. Right after installation it booted the DomO kernel from linux-image-2.6.26-1-xen-amd64 without any problems, but every subsequent restart failed completely. Once I had a XEN "early fatal page fault" error message, on every other of