Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3827672ybt; Tue, 23 Jun 2020 11:41:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxJJdJhM4MHcAuF3OQrOou00J4UgwMWotLbwyb6U0Xs+KCfKYw3DFZ/SSul3Mnn9N6a/VyH X-Received: by 2002:a05:6402:228a:: with SMTP id cw10mr22324694edb.147.1592937699437; Tue, 23 Jun 2020 11:41:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592937699; cv=none; d=google.com; s=arc-20160816; b=imOt9gnpfazFDomnP69i0+9duCORlFrDs7HvggAS2P3/IcNVChXadmjivQmCQsvjLr WyGWM/VJZfqJzj/tIp/8uls/XOScpN0ivSHTBf4pp3kxwmudN3cB983mpbLBDSO2bhbB GNjRmstSFrYHw3WLeJPKErTYJL5z04d7PUAH/Y37q/gfFjaZQyEFNEcBNpZwWtC+xnr2 AxwXYUA0Cc1xGw2Cv0xGldSf2YUaGzpPMKNvpsNuk/lLJ/4lvbCa1aXnK9WIsXDHZrxF k1ToOV+00AA4DlRA0zRMexhDJosGcIDP+EI4QFCh4+Bj7BZEnmpU/5P5rUFP6nKlVYyu Ts3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=MMSXyImcuZBfchMfbTmyyDTCpqvru9kfQ2n1P5epXmU=; b=ZQbN+9oGgT3toMoXOoZmy+mKpYpwQ46/iP3scHBze7d6L0HO0b9zrgQMFTsTISJ+9h Buwu4Pyy3jbJxopd5KHr2fOIzXssAhXw0V2HKlxO5dGn8fGtMcDuSl1VXrI9iozyVnmx uwov2SAPBtbN+iJwbXeu19fw++rt6WsG7tkWebb4wVH3tlNbs+hqoECLIT/pKZHEcLZM j1rEv4YW9JvZeeQEWC4kBvKNMDxqvCvX5V6WH4Wi0u9ckVggMKuH5veyLzjBshQeGQqt rl1K10Zo3pPcURq/GxJUCanNR8qUzveAmptVMhgFoROw9cm+L5R9BxAFw8x1BiDltJER V03w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=E5nOfASC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f11si11063811edn.268.2020.06.23.11.41.16; Tue, 23 Jun 2020 11:41:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=E5nOfASC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387419AbgFWSj3 (ORCPT + 99 others); Tue, 23 Jun 2020 14:39:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733291AbgFWSj2 (ORCPT ); Tue, 23 Jun 2020 14:39:28 -0400 Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3073C061573 for ; Tue, 23 Jun 2020 11:39:28 -0700 (PDT) Received: by mail-il1-x141.google.com with SMTP id l9so5651700ilq.12 for ; Tue, 23 Jun 2020 11:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MMSXyImcuZBfchMfbTmyyDTCpqvru9kfQ2n1P5epXmU=; b=E5nOfASCg0KLZfYJnx0RJBrvw0hgcvN7agf/yEALoOKoOyqGyeo3GlF7vqZCUrEiIG jRd0GMymTl2YWbQTClWJejZ5GGd///O97/aV/0gtqbPe5RnmLLIOkGdYXAVQuNqHCqs7 ZvH1YD9BnuVTb5ug86OCQpg7SBm54T6Cy9VdyUdQu8MMK7RQeBSIIkt2eXu7hp136ZOI ilAkCuJ85pz6Wuh+oiozpw0Pz0+MgkDbQw1UsJjqUeHepSjJyrvwKSUUYGggdNv17iCe iHkPhSEhV5F8Z1v96uSmRoU0pvlttTsVgI7o/GnpsV1WTeIeJRue/PFkFMQoaMJ8VIf7 ErLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MMSXyImcuZBfchMfbTmyyDTCpqvru9kfQ2n1P5epXmU=; b=slsuTTd8I4NsQqqmHYl/Jazsk9bJnDrr1Ls219Ztm8D68qbwv06WAZPd/M3QA8zm8U eUOyhkSUj8yUG2W0A6JJqs5Gp+Ml66o8S+JijQRnD7LSLADV9BZ8mkakaT+dz8Z8z8xF ACev/YcFXI7So5Zs0IWbKoByuiRMA89P145zy8/VIEyaBmBxEN1CMQQT3fwmMWW//5YV 1yhEitY8PZd2yc+55qE7KQo8x23ZX0Kh3r3eNEJlBqz0KYwzlCzi4P/EJ3UspmSXHqel eHOjkO4zBO+o9aKSoKowzeE22IhjFGcCAQOMfKC7E3bh/UeswA94OIBlv4xhPfNgMLBU wpyg== X-Gm-Message-State: AOAM530bykmNjsjrY6uYCj7Smz+pnDClLBE7I8uiMR1iH+Od8O6EEDTH 9pwg1yZVEd7Ho7GbiPAvm/sgS4utpuwV+FTKYH5BSg== X-Received: by 2002:a05:6e02:cd:: with SMTP id r13mr18549799ilq.119.1592937567599; Tue, 23 Jun 2020 11:39:27 -0700 (PDT) MIME-Version: 1.0 References: <20200623063530.81917-1-like.xu@linux.intel.com> <20200623182910.GA24107@linux.intel.com> In-Reply-To: <20200623182910.GA24107@linux.intel.com> From: Jim Mattson Date: Tue, 23 Jun 2020 11:39:16 -0700 Message-ID: Subject: Re: [PATCH] KVM: X86: Emulate APERF/MPERF to report actual VCPU frequency To: Sean Christopherson 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?