All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Chen Yu <yu.c.chen@intel.com>
Cc: mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com,
	rjw@rjwysocki.net, pavel@ucw.cz, len.brown@intel.com,
	luto@kernel.org, bp@suse.de, linux@horizon.com,
	marcin.kaszewski@intel.com, linux-pm@vger.kernel.org,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][v7] x86, suspend: Save/restore extra MSR registers for suspend
Date: Thu, 26 Nov 2015 10:09:40 +0100	[thread overview]
Message-ID: <20151126090940.GA30403@gmail.com> (raw)
In-Reply-To: <c9abdcbc173dd2f57e8990e304376f19287e92ba.1448382971.git.yu.c.chen@intel.com>


* Chen Yu <yu.c.chen@intel.com> wrote:

> A bug was reported that on certain Broadwell platforms, after resuming from S3,
> the CPU is running at an anomalously low speed.
> 
> It turns out that the BIOS has modified the value of the THERM_CONTROL register
> during S3, and changed it from 0 to 0x10, thus enabled clock modulation(bit4),
> but with undefined CPU Duty Cycle(bit1:3) - which causes the problem.
> 
> Here is a simple scenario to reproduce the issue:
> 
>  1. Boot up the system
>  2. Get MSR 0x19a, it should be 0
>  3. Put the system into sleep, then wake it up
>  4. Get MSR 0x19a, it shows 0x10, while it should be 0
> 
> Although some BIOSen want to change the CPU Duty Cycle during S3, in our case we
> don't want the BIOS to do any modification.
> 
> Fix this issue by introducing a more generic x86 framework to save/restore
> specified MSR registers(THERM_CONTROL in this case) for suspend/resume. This
> allows us to fix similar bugs in a much simpler way in the future.
> 
> When the kernel wants to protect certain MSRs during suspending, we simply add a
> quirk entry in msr_save_dmi_table, and customize the MSR registers inside the
> quirk callback, for example:
> 
>   u32 msr_id_need_to_save[] = {MSR_ID0, MSR_ID1, MSR_ID2...};
> 
> and the quirk mechanism ensures that, once resumed from suspend, the MSRs
> indicated by these IDs will be restored to their original, pre-suspend values.
> 
> Since both 64-bit and 32-bit kernels are affected, this patch covers the common
> 64/32-bit suspend/resume code path. And because the MSRs specified by the user
> might not be available or readable in any situation, we use rdmsrl_safe() to
> safely save these MSRs.
> 
> Reported-and-tested-by: Marcin Kaszewski <marcin.kaszewski@intel.com>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Acked-by: Pavel Machek <pavel@ucw.cz>
> Signed-off-by: Chen Yu <yu.c.chen@intel.com>
> ---
> v7:
>  - Use the improved version of changelog, and
>    modify the patch according to:
>    https://patchwork.kernel.org/patch/7637861/
> ---
>  arch/x86/include/asm/msr.h        | 10 +++++
>  arch/x86/include/asm/suspend_32.h |  1 +
>  arch/x86/include/asm/suspend_64.h |  1 +
>  arch/x86/power/cpu.c              | 94 +++++++++++++++++++++++++++++++++++++++
>  4 files changed, 106 insertions(+)

Ok, this version looks mostly good - I've applied it with some other minor edits 
to field and variable naming. Please double check the end result that you'll see 
in the tip-bot notification email once I've pushed it out after some testing.

Thanks,

	Ingo

  reply	other threads:[~2015-11-26  9:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-24 17:03 [PATCH][v7] x86, suspend: Save/restore extra MSR registers for suspend Chen Yu
2015-11-26  9:09 ` Ingo Molnar [this message]
2015-11-26 15:34   ` Chen, Yu C
2016-05-24 16:09     ` Len Brown
2016-05-25  5:02       ` Chen Yu
2015-11-27  7:42 ` [tip:x86/platform] x86/pm: Introduce quirk framework to save/ restore extra MSR registers around suspend/resume tip-bot for Chen Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151126090940.GA30403@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@suse.de \
    --cc=hpa@zytor.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@horizon.com \
    --cc=luto@kernel.org \
    --cc=marcin.kaszewski@intel.com \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yu.c.chen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.