From: Dirk Brandewie <dirk.brandewie@gmail.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: Gleb Natapov <gleb@minantech.com>,
Kashyap Chamarthy <kchamart@redhat.com>,
Josh Boyer <jwboyer@fedoraproject.org>,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
Viresh Kumar <viresh.kumar@linaro.org>,
"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>,
Linux PM list <linux-pm@vger.kernel.org>,
"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
"Richard W.M. Jones" <rjones@redhat.com>
Subject: Re: intel_pstate divide error with v3.13-rc4-256-gb7000ad
Date: Mon, 06 Jan 2014 10:40:39 -0800 [thread overview]
Message-ID: <52CAF8A7.6000705@gmail.com> (raw)
In-Reply-To: <46313552.v2plfSZzzF@vostro.rjw.lan>
On 01/06/2014 03:37 AM, Rafael J. Wysocki wrote:
> On Monday, January 06, 2014 12:20:32 PM Paolo Bonzini wrote:
>> Il 04/01/2014 22:38, Rafael J. Wysocki ha scritto:
>>> On Saturday, January 04, 2014 07:48:13 PM Gleb Natapov wrote:
>>>> On Sat, Jan 04, 2014 at 06:38:59PM +0100, Paolo Bonzini wrote:
>>>>> Il 04/01/2014 15:38, Rafael J. Wysocki ha scritto:
>>>>>> Well, it's just a sanity check and it makes the problem go away for the reporter.
>>>>>>
>>>>>>>> Your patch is welcome but perhaps it should have a WARN_ON too.
>>>>>> It has been pulled in already, so the WARN_ON() can only be added via a separate
>>>>>> patch now. Would you like to prepare that patch?
>>>>>
>>>>> Yes, I'll add it together with the CPUID check. I'll send the patch so
>>>>> that it can get into 3.14.
>>>>>
>>>> CPUID check, while correct, will sweep the problem under the rug. Current
>>>> Linux logic should detect non working pstate in KVM. We should look into
>>>> why this is not happening for nested.
>>>
>>> I agree. It's better not to use CPUID for that in my opinion.
>>
>> Among hypervisors, RHEL5's Xen is probably one of the oldest in actual
>> use with new hardware and new kernels, and the CPUID bit has been fixed
>> in 2011. Older versions wouldn't run new kernels due to other CPUID
>> bits not being cleared properly in VMs.
>>
>> Is there real hardware that has the CPUID bit set and non-working
>> pstate? If there's no such real hardware, CPUID is what the SDM says
>> you should use to detect presence of the APERF/MPERF msrs.
>
> OK
>
>> Having extra safety checks is fine on top of what the SDM says, but IMO
>> they should be WARN_ONs. Otherwise you are sweeping bugs under the rug
>> just as much.
>
> As I said I'm not against adding WARN_ON()s there. :-)
>
The patch below adds a feature check for APERF/MPERF. With this patch
you should NOT see "Intel P-state driver initializing." in dmesg for KVM.
commit 4279f36818bd3ac42f077de114b17eb27d81d482
Author: Dirk Brandewie <dirk.j.brandewie@intel.com>
Date: Mon Jan 6 10:19:38 2014 -0800
intel_pstate: Add X86_FEATURE_APERFMPERF to cpu match parameters.
KVM environments do not support APERF/MPERF MSRs. intel_pstate cannot
operate without these registers.
The previous validity checks in intel_pstate_msrs_not_valid() are
insufficent in nested KVMs.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1046317
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
---
drivers/cpufreq/intel_pstate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 0f63f5d..fe91dad 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -619,7 +619,8 @@ static void intel_pstate_timer_func(unsigned long __data)
}
#define ICPU(model, policy) \
- { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&policy }
+ { X86_VENDOR_INTEL, 6, model, X86_FEATURE_APERFMPERF,\
+ (unsigned long)&policy }
static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
ICPU(0x2a, core_params),
next prev parent reply other threads:[~2014-01-06 18:40 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-24 14:36 intel_pstate divide error with v3.13-rc4-256-gb7000ad Josh Boyer
2013-12-24 16:06 ` Viresh Kumar
2013-12-27 12:24 ` One Thousand Gnomes
2013-12-27 12:47 ` Gleb Natapov
2013-12-27 13:46 ` Josh Boyer
2013-12-27 14:15 ` Kashyap Chamarthy
2013-12-27 14:34 ` Richard W.M. Jones
2013-12-27 16:52 ` Gleb Natapov
2013-12-27 17:01 ` Gleb Natapov
2013-12-27 17:17 ` Richard W.M. Jones
2013-12-27 17:17 ` Kashyap Chamarthy
2013-12-27 21:51 ` Rafael J. Wysocki
2013-12-29 12:12 ` Kashyap Chamarthy
2013-12-29 15:04 ` Rafael J. Wysocki
2013-12-30 14:58 ` Kashyap Chamarthy
2013-12-31 2:07 ` Rafael J. Wysocki
2014-01-03 17:30 ` Dirk Brandewie
2014-01-03 18:04 ` Gleb Natapov
2014-01-03 20:00 ` Dirk Brandewie
2014-01-03 22:06 ` Paolo Bonzini
2014-01-06 17:18 ` Dirk Brandewie
2014-01-07 16:11 ` Gleb Natapov
2014-01-03 22:46 ` Rafael J. Wysocki
2014-01-04 8:35 ` Paolo Bonzini
2014-01-04 14:38 ` Rafael J. Wysocki
2014-01-04 17:38 ` Paolo Bonzini
2014-01-04 17:48 ` Gleb Natapov
2014-01-04 21:38 ` Rafael J. Wysocki
2014-01-06 11:20 ` Paolo Bonzini
2014-01-06 11:37 ` Rafael J. Wysocki
2014-01-06 18:40 ` Dirk Brandewie [this message]
2013-12-27 14:35 ` Rafael J. Wysocki
2013-12-27 14:35 ` Rafael J. Wysocki
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=52CAF8A7.6000705@gmail.com \
--to=dirk.brandewie@gmail.com \
--cc=cpufreq@vger.kernel.org \
--cc=gleb@minantech.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=jwboyer@fedoraproject.org \
--cc=kchamart@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rjones@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.org \
/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.