search for: mwait

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 is about mwa...

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>

...dx(ghcb, ctxt->regs->dx); > > > + > > > + return sev_es_ghcb_hv_call(ghcb, ctxt, SVM_EXIT_MONITOR, 0, 0); > > > > Why? If SVM has the same behavior as VMX, the MONITOR will be disarmed on > > VM-Enter, i.e. the VMM can't do anything useful for MONITOR/MWAIT. I > > assume that's the case given that KVM emulates MONITOR/MWAIT as NOPs on > > SVM. > > Not sure if it is disarmed on VMRUN, but the MONITOR/MWAIT instructions > are part of the GHCB spec, so they are implemented here. Even if MONITOR/MWAIT somehow works across VMRUN...

...dx(ghcb, ctxt->regs->dx); > > > + > > > + return sev_es_ghcb_hv_call(ghcb, ctxt, SVM_EXIT_MONITOR, 0, 0); > > > > Why? If SVM has the same behavior as VMX, the MONITOR will be disarmed on > > VM-Enter, i.e. the VMM can't do anything useful for MONITOR/MWAIT. I > > assume that's the case given that KVM emulates MONITOR/MWAIT as NOPs on > > SVM. > > Not sure if it is disarmed on VMRUN, but the MONITOR/MWAIT instructions > are part of the GHCB spec, so they are implemented here. Even if MONITOR/MWAIT somehow works across VMRUN...

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 Xen-devel@lists.xen.org http://lists.xen.or...

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

...rcx(ghcb, ctxt->regs->cx); > + ghcb_set_rdx(ghcb, ctxt->regs->dx); > + > + return sev_es_ghcb_hv_call(ghcb, ctxt, SVM_EXIT_MONITOR, 0, 0); Why? If SVM has the same behavior as VMX, the MONITOR will be disarmed on VM-Enter, i.e. the VMM can't do anything useful for MONITOR/MWAIT. I assume that's the case given that KVM emulates MONITOR/MWAIT as NOPs on SVM. > +} > + > static enum es_result vc_handle_exitcode(struct es_em_ctxt *ctxt, > struct ghcb *ghcb, > unsigned long exit_code) > @@ -860,6 +876,9 @@ static enum es_result vc_handle_e...

...rcx(ghcb, ctxt->regs->cx); > + ghcb_set_rdx(ghcb, ctxt->regs->dx); > + > + return sev_es_ghcb_hv_call(ghcb, ctxt, SVM_EXIT_MONITOR, 0, 0); Why? If SVM has the same behavior as VMX, the MONITOR will be disarmed on VM-Enter, i.e. the VMM can't do anything useful for MONITOR/MWAIT. I assume that's the case given that KVM emulates MONITOR/MWAIT as NOPs on SVM. > +} > + > static enum es_result vc_handle_exitcode(struct es_em_ctxt *ctxt, > struct ghcb *ghcb, > unsigned long exit_code) > @@ -860,6 +876,9 @@ static enum es_result vc_handle_e...

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 Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...t->regs->dx); >>>> + >>>> + return sev_es_ghcb_hv_call(ghcb, ctxt, SVM_EXIT_MONITOR, 0, 0); >>> >>> Why? If SVM has the same behavior as VMX, the MONITOR will be disarmed on >>> VM-Enter, i.e. the VMM can't do anything useful for MONITOR/MWAIT. I >>> assume that's the case given that KVM emulates MONITOR/MWAIT as NOPs on >>> SVM. >> >> Not sure if it is disarmed on VMRUN, but the MONITOR/MWAIT instructions >> are part of the GHCB spec, so they are implemented here. > > Even if MONITOR/MWAIT...

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 l...

Hi, Keir, In debugging the issue "system hang when doing cpu offline", I identified a situation that could cause a dead lock. The scenario is: mwait_idle_with_hint inside play_dead will access per cpu variable, which causes #PF. The #PF handler will use printk, which will schedule a tasklet. In scheduling a tasklet, per cpu variables are needed, otherwise, there will be another #PF. These series of #PF produce a dead lock around tasklet_lock....

From ba9abf6ee7e5fe0515e2d51b14743c8d5416285c Mon Sep 17 00:00:00 2001 From: Liu, Jinsong <jinsong.liu@intel.com> Date: Fri, 24 Feb 2012 02:18:02 +0800 Subject: [PATCH 2/2] Xen pad logic This patch implement Xen pad logic, and when getting pad device notification, it hypercalls to Xen hypervisor for core parking. Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> ---

...ervisor error (-22) for ACPI CPU11 [ 32.728168] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU12 [ 32.728172] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU13 [ 32.728176] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14 xl dmesg: (XEN) Monitor-Mwait will be used to enter C1 state (XEN) Monitor-Mwait will be used to enter C3 state (XEN) no cpu_id for acpi_id 8 (XEN) no cpu_id for acpi_id 9 (XEN) no cpu_id for acpi_id 10 (XEN) no cpu_id for acpi_id 11 (XEN) no cpu_id for acpi_id 12 (XEN) no cpu_id for acpi_id 13 (XEN) no cpu_id for acpi_id 14...

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) += default_driver.o...

...hen be wiped out by the fall-through code. I''m thinking something like this. Let me know if I have misunderstood something. + case 0xd: /* XSAVE */ + if (!xsave_enabled(current)) + __clear_bit(X86_FEATURE_XSAVEOPT % 32, &a); + break; case 5: /* MONITOR/MWAIT */ Roger R. Cruz ---------------------- Linux starting with 2.6.36 uses the XSAVEOPT instruction and has certain code paths that look only at the feature bit reported through CPUID leaf 0xd sub-leaf 1 (i.e. without qualifying the check with one evaluating leaf 4 output). Consequently the hypervi...

...); > > + ghcb_set_rdx(ghcb, ctxt->regs->dx); > > + > > + return sev_es_ghcb_hv_call(ghcb, ctxt, SVM_EXIT_MONITOR, 0, 0); > > Why? If SVM has the same behavior as VMX, the MONITOR will be disarmed on > VM-Enter, i.e. the VMM can't do anything useful for MONITOR/MWAIT. I > assume that's the case given that KVM emulates MONITOR/MWAIT as NOPs on > SVM. Not sure if it is disarmed on VMRUN, but the MONITOR/MWAIT instructions are part of the GHCB spec, so they are implemented here. Joerg

...@@ -935,7 +935,6 @@ static void set_cx( } cx->latency = xen_cx->latency; - cx->power = xen_cx->power; cx->target_residency = cx->latency * latency_factor; if ( cx->type == ACPI_STATE_C1 || cx->type == ACPI_STATE_C2 ) --- a/xen/arch/x86/cpu/mwait-idle.c +++ b/xen/arch/x86/cpu/mwait-idle.c @@ -96,7 +96,6 @@ static const struct cpuidle_state { char name[16]; unsigned int flags; unsigned int exit_latency; /* in US */ - int power_usage; /* in mW */ unsigned int target_residency; /* in US */ } *cpuidle_state_table; @@ -479,7 +478,6...

...r 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 resulting in significantly higher power savings. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com> diff -r a7bacdc5449a -r 99df5c6b2964 xen/arch/x86/acpi/cpu_idle.c --- a/xen/arch/x86/acpi/cpu_idle.c Mon Feb 27 17:05:18 2012...

...Fri Mar 11 17:18:01 2011 +0000 x86: Fix cpu offline bug: cancel SYSIO method when play dead Play dead is a fragile and tricky point of cpu offline logic. For how to play cpu dead, linux kernel changed several times: Very old kernel support 3 ways to play cpu dead: mwait, SYSIO, and halt, just like what cpuidle did when enter C3; Later, it cancel mwait and SYSIO support, only use halt to play dead; Latest linux 2.6.38 add mwait support when cpu dead. This patch cancel SYSIO method when cpu dead, keep same with latest kernel. SYSIO...