From patchwork Fri Dec 2 20:58:34 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Don Bowman X-Patchwork-Id: 9459187 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9213760515 for ; Fri, 2 Dec 2016 20:58:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 819A928599 for ; Fri, 2 Dec 2016 20:58:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 766ED285B7; Fri, 2 Dec 2016 20:58:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6757928599 for ; Fri, 2 Dec 2016 20:58:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754040AbcLBU6i (ORCPT ); Fri, 2 Dec 2016 15:58:38 -0500 Received: from mail-wj0-f181.google.com ([209.85.210.181]:34861 "EHLO mail-wj0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751786AbcLBU6g (ORCPT ); Fri, 2 Dec 2016 15:58:36 -0500 Received: by mail-wj0-f181.google.com with SMTP id v7so241807032wjy.2 for ; Fri, 02 Dec 2016 12:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=donbowman-ca.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PWoPesx5hY8pEuwePv+ItFpbL7XYzW7KT710OrjRfjY=; b=KPQ6847MpkxpPBPbpeBZAWTT/XLyeL26mp+lvlPVa7H21PkqXzvFcmnCYjJNEbq87i CNXCkE4sNoriqQnBo8mjAeMf8PYnkRxt+BNHJoeSLQ1gdacAgEDKvIsl/lh4thgSRWK6 44rVv2bm6U6YkntpSWz5KSWpqpN7EG3ULyCrYsAp3Kxis6GLeT4AEJpQSLoH0BTWkar7 hMLHyNtMcHSNHJ5cyx7RE8I/0TM98Oq695CavUUJTlCSj3N15HW1If78ZiKK+M8HL7BM bs953vO1rM7BcL8CGNn8+VhiwSXRIWfHJR3eG2PtM7gD49N/WUveKhz/4UNeT1gLYyPR vvCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PWoPesx5hY8pEuwePv+ItFpbL7XYzW7KT710OrjRfjY=; b=b253TftVf2SvpvWx6VefcxNB9QFxUzNw0i9mHqr2tzrufvQ1dUONodbbgJ3QeIroM+ jE501/H+EkV2jlx50D9dsQZz1jUXqja0b64bqyXq+tgn7osY/0+EfPIdqaKQQ1Ad0rMx l0hBQ/5jxO5DORcD70zohMIV16IdE0dLyQoW59pbAAMFcv1tZrfw+9IIeCP89EaRpLOm 5WEVravU1OiwFOEwUVNXM4yyypt1GqWfbybP/EHVTgwPSWPXzSa2mG8nnQw3k0SI9zHx c7g4bH6j7zn55JeFfuq7txgm0XPgSWXJeUChk9AzbSBEDpTosSyDmnOykXVJHKJSh6r9 5lFw== X-Gm-Message-State: AKaTC03UfB5vn5sUpVYkkfP+WbRhlPnhkvnBBIZa9GYW7ZlS1Q+gFBbVj/ObWnj6Tm4g+cbLeNi65Haq31FvxA== X-Received: by 10.194.220.230 with SMTP id pz6mr40038825wjc.81.1480712315182; Fri, 02 Dec 2016 12:58:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.163.195 with HTTP; Fri, 2 Dec 2016 12:58:34 -0800 (PST) X-Originating-IP: [99.253.158.32] In-Reply-To: References: <20161202150632.GA22204@potion> From: Don Bowman Date: Fri, 2 Dec 2016 15:58:34 -0500 Message-ID: Subject: Re: PATCH: setup_vmcs_config: disable TSC scaling on unlike processors To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Cc: kvm@vger.kernel.org, pbonzini@redhat.com Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 2 December 2016 at 14:10, Don Bowman wrote: > On 2 December 2016 at 10:07, Radim Krčmář wrote: >> Subjects that touch only arch/x86/kvm/vmx.c are usually prefixed with >> "[PATCH] KVM: VMX:". >> >> 2016-12-01 21:32-0500, Don Bowman: >>> Add an enable_tsc_scaling parameter to kvm >>> >>> Signed-off-by: Don Bowman >>> --- >>> >>> My system has what i thought were two identical processors (same >>> stepping ID etc). >>> However, bafflingly, one of them has the ability to do TSC scaling, >>> and one does not (as reported in the vmcs). >> >> Wow, the chip doesn't sound trustworthy. > OK, how about this? The check has to be in setup_vmcs_config() not elsewhere I think. This is where the rdmsr occurs, and immediately following that is the compare against the other processor(s). Unless I'm missing something I don't see how vmx_secondary_exec_control() could work. For the enable I was following the 'enable_pml' which is already there, but have changed it below. vmx_check_processor_compat() calls setup_vmcs_config() and then the memcmp() immediately afterwards. static bool __read_mostly enable_pml = 1; @@ -3449,6 +3452,8 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf) vmcs_conf->pin_based_exec_ctrl = _pin_based_exec_control; vmcs_conf->cpu_based_exec_ctrl = _cpu_based_exec_control; vmcs_conf->cpu_based_2nd_exec_ctrl = _cpu_based_2nd_exec_control; + if (!tsc_scaling) + vmcs_conf->cpu_based_2nd_exec_ctrl &= ~SECONDARY_EXEC_TSC_SCALING; vmcs_conf->vmexit_ctrl = _vmexit_control; vmcs_conf->vmentry_ctrl = _vmentry_control; --- To unsubscribe from this list: send the line "unsubscribe kvm" 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/vmx.c b/arch/x86/kvm/vmx.c index 5382b82..503ee1e 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -103,6 +103,9 @@ module_param_named(enable_shadow_vmcs, enable_shadow_vmcs, bool, S_IRUGO); static bool __read_mostly nested = 0; module_param(nested, bool, S_IRUGO); +static bool __read_mostly tsc_scaling = true; +module_param(tsc_scaling, bool, S_IRUGO); + static u64 __read_mostly host_xss;