similar to: [PATCH 2/2] CPUIDLE: Handle C2 LAPIC timer & TSC stop

[PATCH 1/2] Support multiple C3 states. There may be multiple ACPI C3 states mapped into different CPU C-states.So made some modification to support this case. [PATCH 2/2] Handle C2 LAPIC timer & TSC 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''

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

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

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

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

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, 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

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

we will need a always running therm daemon to adjust the voltage/clocks on the fly. Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/nvkm/subdev/therm/base.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/therm/base.c b/drm/nouveau/nvkm/subdev/therm/base.c index 8894fee..0c0feec 100644 ---

Change from v2: re-written code in ''vmx_intr_assist'' into if()/else if() sequence to make code change easy to review. Virtual interrupt delivery avoids Xen to inject vAPIC interrupts manually, which is fully taken care of by the hardware. This needs some special awareness into existing interrupr injection path: For pending interrupt from vLAPIC, instead of direct injection, we

I do not seem to be able to get any where with the power management functions. I have had a look at the xenpm Wiki page, but it hasn''t helped. Its probably something completely obvious, but I can''t see it. I running Xen 3.4.0 on Centos 5.3 x86_64 using the gitco RPMs on an Intel S5000PSL motherboard with 2 x Xeon 5410s. Dom0 is running the latest Centos 5.3 kernel. My xm

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

Hello Ian, i?ve tried to install "xen-linux-system-amd64" on a VMware host again and everything went fine. The Installation completes and i can boot into Xen und boot up the Dom0. So, you were right. It seems to be a problem with the initscript, but as far as i can tell, only when running xen under xen. To me, this specific issue is resolved, since the meta-package seems to install

Hi Sydney, Thanks for all the info. I'd like to have the initscript work sensibly in this scenario at some point (not for Jessie though, it's too late now) so I think we may as well keep this bug around to track that since it already contains a bunch of useful information. Thanks, Ian. On Tue, 2014-12-30 at 00:39 +0100, Sydney Meyer wrote: > Hello Ian, > > i?ve tried to

> On 23 Dec 2014, at 12:59, Ian Campbell <ijc at debian.org> wrote: > > Control: reassign -1 xen-utils-common 4.4.1-6 > Control: retitle -1 /etc/init.d/xen fails when run in a guest, causing postinst to fail. > > Seems like this issue is in the Xen packages not in the xen-linux-system > metapackage, so reassigning. > > On Mon, 2014-12-22 at 23:01 +0100, Sydney