* [PATCH] x86/cpuidle: publish new states only after fully initializing them
@ 2013-12-10 15:26 Jan Beulich
2013-12-10 15:40 ` Andrew Cooper
2013-12-11 6:39 ` Liu, Jinsong
0 siblings, 2 replies; 3+ messages in thread
From: Jan Beulich @ 2013-12-10 15:26 UTC (permalink / raw)
To: xen-devel; +Cc: Jinsong Liu, Keir Fraser
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]
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>
--- 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;
}
[-- Attachment #2: x86-cpuidle-set_cx.patch --]
[-- Type: text/plain, Size: 1244 bytes --]
x86/cpuidle: publish new states only after fully initializing them
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>
--- 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;
}
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] x86/cpuidle: publish new states only after fully initializing them
2013-12-10 15:26 [PATCH] x86/cpuidle: publish new states only after fully initializing them Jan Beulich
@ 2013-12-10 15:40 ` Andrew Cooper
2013-12-11 6:39 ` Liu, Jinsong
1 sibling, 0 replies; 3+ messages in thread
From: Andrew Cooper @ 2013-12-10 15:40 UTC (permalink / raw)
To: Jan Beulich; +Cc: Jinsong Liu, xen-devel, Keir Fraser
[-- Attachment #1.1: Type: text/plain, Size: 1448 bytes --]
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
[-- Attachment #1.2: Type: text/html, Size: 2364 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] x86/cpuidle: publish new states only after fully initializing them
2013-12-10 15:26 [PATCH] x86/cpuidle: publish new states only after fully initializing them Jan Beulich
2013-12-10 15:40 ` Andrew Cooper
@ 2013-12-11 6:39 ` Liu, Jinsong
1 sibling, 0 replies; 3+ messages in thread
From: Liu, Jinsong @ 2013-12-11 6:39 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: Keir Fraser
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: Liu Jinsong <jinsong.liu@intel.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-12-11 6:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-10 15:26 [PATCH] x86/cpuidle: publish new states only after fully initializing them Jan Beulich
2013-12-10 15:40 ` Andrew Cooper
2013-12-11 6:39 ` Liu, Jinsong
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).