From patchwork Fri Jan 3 20:00:01 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: dirk.brandewie@gmail.com X-Patchwork-Id: 3432521 Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id D1DD3C02DC for ; Fri, 3 Jan 2014 20:00:05 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6A9FD2011D for ; Fri, 3 Jan 2014 20:00:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 77B9720114 for ; Fri, 3 Jan 2014 20:00:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753485AbaACUAA (ORCPT ); Fri, 3 Jan 2014 15:00:00 -0500 Received: from mail-pd0-f177.google.com ([209.85.192.177]:40434 "EHLO mail-pd0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753438AbaACT77 (ORCPT ); Fri, 3 Jan 2014 14:59:59 -0500 Received: by mail-pd0-f177.google.com with SMTP id q10so15674396pdj.36 for ; Fri, 03 Jan 2014 11:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LLwiJ4Rd4t4dsQgqbzw2ELovzxUVVxy2cfjxcHO15bE=; b=mfzxAqFGUNYxdKtZCc8s36u4zTW8dhZBqf/2jlAsjdy4/eOTOmQ9FlXpNGOqlnR4J/ 8ERjUxy1ROeUBoqoW4aE7o1QZv+UjRpSKQIbD/GzK320iEx5gF/UNnnc0H2rq6kXyulF ETgryh0aYNXQxLyTlp1T+a9Gkqeeh7Jlz+5Nzhc4n54o0V2On3RkLG9+cJ6emZliTpNE /zD4+5qPvkaDbyRtN6ZusZdXh8FDjToCzYGGXvY7oU1q2YlhRTDq7NdZWSWgllIOCo52 f8N+SDK1TF/z2enLG7vr4MUAkpAWKwXYWaBSalfWp6kAJuDBU5jIkjuTJHIxpR1jnr8/ tOcQ== X-Received: by 10.66.26.231 with SMTP id o7mr58405367pag.109.1388779198837; Fri, 03 Jan 2014 11:59:58 -0800 (PST) Received: from echolake.localdomain (static-50-43-35-129.bvtn.or.frontiernet.net. [50.43.35.129]) by mx.google.com with ESMTPSA id qf7sm145029522pac.14.2014.01.03.11.59.57 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 03 Jan 2014 11:59:58 -0800 (PST) Message-ID: <52C716C1.6070704@gmail.com> Date: Fri, 03 Jan 2014 12:00:01 -0800 From: Dirk Brandewie User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Gleb Natapov CC: "Rafael J. Wysocki" , Kashyap Chamarthy , Josh Boyer , One Thousand Gnomes , Viresh Kumar , "cpufreq@vger.kernel.org" , Linux PM list , "Linux-Kernel@Vger. Kernel. Org" , "Richard W.M. Jones" Subject: Re: intel_pstate divide error with v3.13-rc4-256-gb7000ad References: <4794554.Hmd2RUNYDT@vostro.rjw.lan> <52C18A23.10703@redhat.com> <3710588.K8glfx1cYs@vostro.rjw.lan> <52C6F3B4.3050904@gmail.com> <20140103180435.GK10961@minantech.com> In-Reply-To: <20140103180435.GK10961@minantech.com> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 01/03/2014 10:04 AM, Gleb Natapov wrote: > On Fri, Jan 03, 2014 at 09:30:28AM -0800, Dirk Brandewie wrote: >> Hi All, >> >> Sorry for being late to the party but I just got back from vacation. >> >> There is something deeply wrong here. We should have never gotten to >> intel_pstate_init_cpu(). The VM had to have returned value from the read >> of the max pstate at driver init time and 0 when the CPU was being brought up. >> >> intel_pstate_msrs_not_valid() was added to solve this issue early on >> if I remember correctly it was Josh that reported it then. Is there >> a definative way to detect whether we are running in a VM? >> > Checking for VM is a wrong thing to do here. KVM should behave like it > does not support p-state. > >> Can some one tell me how the nested environment differs in regards to >> reading MSRs? >> > It shouldn't differ, but there may be bug somewhere in nested emulation. > We shouldn't try and hind the bug by doing more checks in Linux but > rather fixing KVM bug that causes Linux to behave incorrectly. Based on the unhandled MSR messages in the host dmesg the following patch should make sure the correct values are returned for PLAT_FORM_INFO, APERF and MPERF. intel_pstate and turbostat are the only users of these registers. Could you try the folloinw patch minus Rafael's patch please. Compile tested only. TIA --Dirk commit 5594b89bee7f83200c1a70bf95d50ac35e4fe3f8 Author: Dirk Brandewie Date: Fri Jan 3 11:44:15 2014 -0800 x86/kvm: Handle MSR_PLATFORM_INFO, MSR_IA32_MPERF and MSR_IA32_APERF MSRs Handle MSRs correctly when read from a nested KVM Signed-off-by: Dirk Brandewie --- arch/x86/kvm/x86.c | 3 +++ 1 file changed, 3 insertions(+) case MSR_IA32_LASTBRANCHFROMIP: -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 5d004da..390ef27 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2336,6 +2336,9 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata) switch (msr) { case MSR_IA32_PLATFORM_ID: + case MSR_IA32_MPERF: + case MSR_IA32_APERF: + case MSR_PLATFORM_INFO: case MSR_IA32_EBL_CR_POWERON: case MSR_IA32_DEBUGCTLMSR: