From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6BB7EC433E0 for ; Tue, 23 Jun 2020 19:05:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 50963207FB for ; Tue, 23 Jun 2020 19:05:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733248AbgFWTFI (ORCPT ); Tue, 23 Jun 2020 15:05:08 -0400 Received: from mga12.intel.com ([192.55.52.136]:30096 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733138AbgFWTFI (ORCPT ); Tue, 23 Jun 2020 15:05:08 -0400 IronPort-SDR: Zj6Oc6+RSg+O8gIKqtbcRDOP/aJObN2iAV96FP32RaamC3N9/N76An69uZl/FYyyJDI+KOvhZb DP0gO5aSJREw== X-IronPort-AV: E=McAfee;i="6000,8403,9661"; a="123874407" X-IronPort-AV: E=Sophos;i="5.75,272,1589266800"; d="scan'208";a="123874407" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2020 12:05:05 -0700 IronPort-SDR: Chcib1/+wuz5WjhZ0050ny00zBjMRvXvTvNn3tklhvytgw8+sR8FvVU90+35xP2RxmCjhmwSjR mKS0w4Ebbh6Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,272,1589266800"; d="scan'208";a="287431388" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.152]) by orsmga007.jf.intel.com with ESMTP; 23 Jun 2020 12:05:04 -0700 Date: Tue, 23 Jun 2020 12:05:04 -0700 From: Sean Christopherson To: Jim Mattson Cc: Like Xu , Paolo Bonzini , kvm list , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , wei.huang2@amd.com, Peter Zijlstra , Thomas Gleixner , LKML , Li RongQing , Chai Wen , Jia Lina Subject: Re: [PATCH] KVM: X86: Emulate APERF/MPERF to report actual VCPU frequency Message-ID: <20200623190504.GC24107@linux.intel.com> References: <20200623063530.81917-1-like.xu@linux.intel.com> <20200623182910.GA24107@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, Jun 23, 2020 at 11:39:16AM -0700, Jim Mattson wrote: > On Tue, Jun 23, 2020 at 11:29 AM Sean Christopherson > wrote: > > > > On Tue, Jun 23, 2020 at 02:35:30PM +0800, Like Xu wrote: > > > The aperf/mperf are used to report current CPU frequency after 7d5905dc14a > > > "x86 / CPU: Always show current CPU frequency in /proc/cpuinfo". But guest > > > kernel always reports a fixed VCPU frequency in the /proc/cpuinfo, which > > > may confuse users especially when turbo is enabled on the host. > > > > > > Emulate guest APERF/MPERF capability based their values on the host. > > > > > > Co-developed-by: Li RongQing > > > Signed-off-by: Li RongQing > > > Reviewed-by: Chai Wen > > > Reviewed-by: Jia Lina > > > Signed-off-by: Like Xu > > > --- > > > > ... > > > > > @@ -8312,7 +8376,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) > > > dm_request_for_irq_injection(vcpu) && > > > kvm_cpu_accept_dm_intr(vcpu); > > > fastpath_t exit_fastpath; > > > - > > > + u64 enter_mperf = 0, enter_aperf = 0, exit_mperf = 0, exit_aperf = 0; > > > bool req_immediate_exit = false; > > > > > > if (kvm_request_pending(vcpu)) { > > > @@ -8516,8 +8580,17 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) > > > vcpu->arch.switch_db_regs &= ~KVM_DEBUGREG_RELOAD; > > > } > > > > > > + if (unlikely(vcpu->arch.hwp.hw_coord_fb_cap)) > > > + get_host_amperf(&enter_mperf, &enter_aperf); > > > + > > > exit_fastpath = kvm_x86_ops.run(vcpu); > > > > > > + if (unlikely(vcpu->arch.hwp.hw_coord_fb_cap)) { > > > + get_host_amperf(&exit_mperf, &exit_aperf); > > > + vcpu_update_amperf(vcpu, get_amperf_delta(enter_aperf, exit_aperf), > > > + get_amperf_delta(enter_mperf, exit_mperf)); > > > + } > > > + > > > > Is there an alternative approach that doesn't require 4 RDMSRs on every VMX > > round trip? That's literally more expensive than VM-Enter + VM-Exit > > combined. > > > > E.g. what about adding KVM_X86_DISABLE_EXITS_APERF_MPERF and exposing the > > MSRs for read when that capability is enabled? > > When would you load the hardware MSRs with the guest/host values? Ugh, I was thinking the MSRs were read-only. Doesn't this also interact with TSC scaling?