similar to: [PATCH 0/3] CPUIDLE: enable C1 FFH

It has never been used for anything, and Linux 3.7 doesn''t propagate this information anymore. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- Konrad, on the pv-ops side it may be better to pass zero rather than leaving the field completely uninitialized. --- a/xen/arch/x86/acpi/cpu_idle.c +++ b/xen/arch/x86/acpi/cpu_idle.c @@ -935,7 +935,6 @@ static void set_cx( }

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

# HG changeset patch # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1330642361 -3600 # Node ID 99df5c6b2964ceaa73651d7bc02fb1ae820f7691 # Parent a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9 x86: Use deep C states for off-lined CPUs Currently when a core is taken off-line it is placed in C1 state (unless MONITOR/MWAIT is used). This patch allows a core to go to deeper C states

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

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

There''re basically two methods to enter a given C-state: legacy (hlt + I/O read), and native(using mwait). MWAIT is always preferred when both underlying CPU and OS support, which is a more efficient way to conduct C-state transition. Xen PM relies on Dom0 to parse ACPI Cx/Px information, which involves one step to notify BIOS about a set of capabilities supported by OSPM. One capability

On 03/23/2011 08:43 AM, Len Brown wrote: > Why is this patch a step forward? Hi Len, I have basically moved the code for arch default and mwait idle from arch/x86/kernel/process.c to a driver. This was suggested by Venki (https://lkml.org/lkml/2010/10/19/460) as part of pm_idle cleanup and direct call of cpuidle_idle_call(). There is not much new code here. > >> +obj-$(CONFIG_X86)

1: x86/mwait_idle: remove assumption of one C-state per MWAIT flag 2: x86/mwait_idle: export both C1 and C1E 3: x86/mwait_idle: initial C8, C9, C10 support Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Jan Beulich <jbeulich@suse.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

flight 6412 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/6412/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-xcpkern-i386-xl-credit2 11 guest-localmigrate fail REGR. vs. 6379 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-win 16

[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''

Enable Px/Cx related CPUID/MSR bits for dom0 to get correct Px/Cx info. Signed-off-by: Wei Gang <gang.wei@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, i''m not sure if i understood the new acpi xen cpufreq driver - here''s the output when loading xen_acpi_processor module in linux 3.4: dom0 dmesg: [ 32.728151] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU8 [ 32.728156] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU9 [ 32.728160] xen-acpi-processor: (CX): Hypervisor error (-22) for

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

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

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>

Matching a similar change in Linux 3.7-rc. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/cpu/mwait-idle.c +++ b/xen/arch/x86/cpu/mwait-idle.c @@ -365,6 +365,7 @@ static struct intel_idle_id { ICPU(0x2a, snb), ICPU(0x2d, snb), ICPU(0x3a, ivb), + ICPU(0x3e, ivb), {} }; _______________________________________________ Xen-devel mailing list

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

On Tue, Mar 22, 2011 at 06:03:28PM +0530, Trinabh Gupta wrote: > This patch implements a default cpuidle driver for xen. > Earlier pm_idle was flipped to default_idle. Maybe there > is a better way to ensure default_idle is called > without using this cpuidle driver. Please also CC the Xen devel mailing list (I did this for you) I couldn''t find it in the description, but I

On Mon, Dec 15, 2014 at 05:54:51PM +0000, Richard W.M. Jones wrote: > No idea why this happens: > > index-parse.y: In function 'yyparse': > index-parse.c:1256:6: error: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Werror=strict-overflow] > if (yyss + yystacksize - 1 <= yyssp) > ^ > > It only happens on one machine,