From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86/cpuidle: publish new states only after fully initializing them Date: Tue, 10 Dec 2013 15:40:21 +0000 Message-ID: <52A735E5.9000503@citrix.com> References: <52A740B5020000780010BEC8@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0512979197419157378==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VqPQE-0003R4-9b for xen-devel@lists.xenproject.org; Tue, 10 Dec 2013 15:40:30 +0000 In-Reply-To: <52A740B5020000780010BEC8@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Jinsong Liu , xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org --===============0512979197419157378== Content-Type: multipart/alternative; boundary="------------070900020600090903080501" --------------070900020600090903080501 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 10/12/13 15:26, Jan Beulich wrote: > Since state information coming from Dom0 can arrive at any time, on > any CPU, we ought to make sure that a new state is fully initialized > before the target CPU might be using it. > > Once touching that code, also do minor cleanup: A missing (but benign) > "break" and some white space adjustments. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper > > --- a/xen/arch/x86/acpi/cpu_idle.c > +++ b/xen/arch/x86/acpi/cpu_idle.c > @@ -912,7 +912,7 @@ static void set_cx( > acpi_power->cpu, xen_cx->type); > return; > } > - cx = &acpi_power->states[acpi_power->count++]; > + cx = &acpi_power->states[acpi_power->count]; > cx->type = xen_cx->type; > break; > } > @@ -937,11 +937,14 @@ static void set_cx( > break; > default: > cx->entry_method = ACPI_CSTATE_EM_NONE; > + break; > } > > - cx->latency = xen_cx->latency; > - > + cx->latency = xen_cx->latency; > cx->target_residency = cx->latency * latency_factor; > + > + smp_wmb(); > + acpi_power->count++; > if ( cx->type == ACPI_STATE_C1 || cx->type == ACPI_STATE_C2 ) > acpi_power->safe_state = cx; > } > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------070900020600090903080501 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 10/12/13 15:26, Jan Beulich wrote:
Since state information coming from Dom0 can arrive at any time, on
any CPU, we ought to make sure that a new state is fully initialized
before the target CPU might be using it.

Once touching that code, also do minor cleanup: A missing (but benign)
"break" and some white space adjustments.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>


--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -912,7 +912,7 @@ static void set_cx(
                    acpi_power->cpu, xen_cx->type);
             return;
         }
-        cx = &acpi_power->states[acpi_power->count++];
+        cx = &acpi_power->states[acpi_power->count];
         cx->type = xen_cx->type;
         break;
     }
@@ -937,11 +937,14 @@ static void set_cx(
         break;
     default:
         cx->entry_method = ACPI_CSTATE_EM_NONE;
+        break;
     }
 
-    cx->latency  = xen_cx->latency;
-    
+    cx->latency = xen_cx->latency;
     cx->target_residency = cx->latency * latency_factor;
+
+    smp_wmb();
+    acpi_power->count++;
     if ( cx->type == ACPI_STATE_C1 || cx->type == ACPI_STATE_C2 )
         acpi_power->safe_state = cx;
 }






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------070900020600090903080501-- --===============0512979197419157378== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0512979197419157378==--