Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1577486ybz; Thu, 23 Apr 2020 01:19:25 -0700 (PDT) X-Google-Smtp-Source: APiQypIdWvN7YINDBjbkbw4hIq7He/LnfiScx0YQT5DBaAs4Zs7OhGAvpQUleRGwfP3o/7ByXKD0 X-Received: by 2002:a50:ee0e:: with SMTP id g14mr1801024eds.34.1587629965417; Thu, 23 Apr 2020 01:19:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587629965; cv=none; d=google.com; s=arc-20160816; b=n6c2wWB+fg0Z9OwU2ciDm2aLANxhr+NMIRkf2UbFzyflc8u9m3z2R+jNyhVV/NuMaS MBlDga+LZbSNssECRpEHSwW+6GDn557TA3qFL//vKW8M/99k/6eltfb+MbBwmDJFehq3 vzhZJeEGU/scwgpGNWFm0ylEAdMk/YDO+71tutbvx4Ekt8o7zvPrtVf5aJM9WU0CbFHE AddpA3nXvc4/yUcgGbsbMKZb89C/scu01rJuwvsrlw83ZlZ4LpdotyjU2COIDCQluQRu uSE2KXQNO4mZ2ukSt/RA6qby8o3fvh6XtyOnT84qtDGBCki7JK44HTInfX31x+TZ7nBo jGkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:ironport-sdr:ironport-sdr; bh=yQEu1m0fzDarjAwfsLoxJ+M6q4aP6xXQgKBT9rWo1vY=; b=IaV1CJW4iRUQ5EMT88uA/eIyzZdUwqsuhSCeBIVpUsjFYofd0u0KNA8KG1ajanX4Yy xeA9g67uWSE9XMe293OWksS3L2UN38kKACZW26jeR00s4vFGHmXZTtybpg/MyKUcH3tU WB+XPOTN0SF+PS/+ujN/uskWoXMEfSv1yqe+Xi0dkVYz24Zmox3JsSiPjtFqY2+FeKYQ mDPBKHua3npYcN+KgJDwQbZD8s7M3W+i792+e/W9rEN2g9YrzdmHGEqw3QaT0QqWWr3t xyNIdoQMIit5pdeuBWOcVz/MggH0WZ33gGNRdFiXujVs+NdkXKyGZB7hlBBNy5pX0jRo a47g== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s18si824743ejr.449.2020.04.23.01.19.01; Thu, 23 Apr 2020 01:19:25 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726421AbgDWIRh (ORCPT + 99 others); Thu, 23 Apr 2020 04:17:37 -0400 Received: from mga18.intel.com ([134.134.136.126]:57581 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725863AbgDWIRh (ORCPT ); Thu, 23 Apr 2020 04:17:37 -0400 IronPort-SDR: V/s19IIxrtlQ44oziXriPiagTkyKmUyZoz82VyXJ0OG79JLbXY+QLHZpcPvwnsTUeNk5Z8Bpzg CuCXVsbWAv3Q== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Apr 2020 01:17:36 -0700 IronPort-SDR: YOkfRaMmuAkWVr0GdonnkthHPBZU+8vdCN6EUZDW3i327Pb/nKOw68KgVPLm6xCDEzlmEd+6t4 CJiT6hxdXbdA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,306,1583222400"; d="scan'208";a="255910029" Received: from sqa-gate.sh.intel.com (HELO clx-ap-likexu.tsp.org) ([10.239.48.212]) by orsmga003.jf.intel.com with ESMTP; 23 Apr 2020 01:17:33 -0700 From: Like Xu To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, wei.w.wang@intel.com, ak@linux.intel.com, Like Xu Subject: [PATCH v10 00/11] Guest Last Branch Recording Enabling Date: Thu, 23 Apr 2020 16:14:01 +0800 Message-Id: <20200423081412.164863-1-like.xu@linux.intel.com> X-Mailer: git-send-email 2.21.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, Please help review your interesting parts in this stable version, e.g. the first five patches involve the perf event subsystem and the sixth patch concerns the KVM userspace interface. v9->v10 Changelog: - new patch (0002) to refactor hw->idx checks and cleanup for host perf; - refine comments in guest LBR constraint patch and rename functions; - still ack LBRS_FROZEN for guest LBR event in the intel_pmu_ack_status(); - add more checks before enabling LBR in the kvm_vm_ioctl_enable_cap(); - add pmu_ops->deliver_pmi to clear LBR enable bit for guest debugctl_msr; - use vmx_supported_perf_capabilities() to expose PDCM via kvm_cpu_cap*(); You may check more details in each commit. Previous: https://lore.kernel.org/kvm/20200313021616.112322-1-like.xu@linux.intel.com/ --- The last branch recording (LBR) is a performance monitor unit (PMU) feature on Intel processors that records a running trace of the most recent branches taken by the processor in the LBR stack. This patch series is going to enable this feature for plenty of KVM guests. The userspace could configure whether it's enabled or not for each guest via vm_ioctl KVM_CAP_X86_GUEST_LBR. As a first step, a guest could only enable LBR feature if its cpu model is the same as the host since the LBR feature is still one of model specific features. If it's enabled on the guest, the guest LBR driver would accesses the LBR MSR (including IA32_DEBUGCTLMSR and records MSRs) as host does. The first guest access on the LBR related MSRs is always interceptible. The KVM trap would create a special LBR event (called guest LBR event) which enables the callstack mode and none of hardware counter is assigned. The host perf would enable and schedule this event as usual. Guest's first access to a LBR registers gets trapped to KVM, which creates a guest LBR perf event. It's a regular LBR perf event which gets the LBR facility assigned from the perf subsystem. Once that succeeds, the LBR stack msrs are passed through to the guest for efficient accesses. However, if another host LBR event comes in and takes over the LBR facility, the LBR msrs will be made interceptible, and guest following accesses to the LBR msrs will be trapped and meaningless. Because saving/restoring tens of LBR MSRs (e.g. 32 LBR stack entries) in VMX transition brings too excessive overhead to frequent vmx transition itself, the guest LBR event would help save/restore the LBR stack msrs during the context switching with the help of native LBR event callstack mechanism, including LBR_SELECT msr. If the guest no longer accesses the LBR-related MSRs within a scheduling time slice and the LBR enable bit is unset, vPMU would release its guest LBR event as a normal event of a unused vPMC and the pass-through state of the LBR stack msrs would be canceled. --- LBR testcase: echo 1 > /proc/sys/kernel/watchdog echo 25 > /proc/sys/kernel/perf_cpu_time_max_percent echo 5000 > /proc/sys/kernel/perf_event_max_sample_rate echo 0 > /proc/sys/kernel/perf_cpu_time_max_percent ./perf record -b ./br_instr a - Perf report on the host: Samples: 72K of event 'cycles', Event count (approx.): 72512 Overhead Command Source Shared Object Source Symbol Target Symbol Basic Block Cycles 12.12% br_instr br_instr [.] cmp_end [.] lfsr_cond 1 11.05% br_instr br_instr [.] lfsr_cond [.] cmp_end 5 8.81% br_instr br_instr [.] lfsr_cond [.] cmp_end 4 5.04% br_instr br_instr [.] cmp_end [.] lfsr_cond 20 4.92% br_instr br_instr [.] lfsr_cond [.] cmp_end 6 4.88% br_instr br_instr [.] cmp_end [.] lfsr_cond 6 4.58% br_instr br_instr [.] cmp_end [.] lfsr_cond 5 - Perf report on the guest: Samples: 92K of event 'cycles', Event count (approx.): 92544 Overhead Command Source Shared Object Source Symbol Target Symbol Basic Block Cycles 12.03% br_instr br_instr [.] cmp_end [.] lfsr_cond 1 11.09% br_instr br_instr [.] lfsr_cond [.] cmp_end 5 8.57% br_instr br_instr [.] lfsr_cond [.] cmp_end 4 5.08% br_instr br_instr [.] lfsr_cond [.] cmp_end 6 5.06% br_instr br_instr [.] cmp_end [.] lfsr_cond 20 4.87% br_instr br_instr [.] cmp_end [.] lfsr_cond 6 4.70% br_instr br_instr [.] cmp_end [.] lfsr_cond 5 Conclusion: the profiling results on the guest are similar to that on the host. Like Xu (8): perf/x86/core: Refactor hw->idx checks and cleanup perf/x86/lbr: Add interface to get basic information about LBR stack perf/x86: Add constraint to create guest LBR event without hw counter perf/x86: Keep LBR stack unchanged in host context for guest LBR event KVM: x86: Add KVM_CAP_X86_GUEST_LBR to dis/enable LBR from user-space KVM: x86/pmu: Add LBR feature emulation via guest LBR event KVM: x86/pmu: Release guest LBR event via vPMU lazy release mechanism KVM: x86: Expose MSR_IA32_PERF_CAPABILITIES for LBR record format Wei Wang (3): perf/x86: Fix variable type for LBR registers KVM: x86/pmu: Tweak kvm_pmu_get_msr to pass 'struct msr_data' in KVM: x86: Remove the common trap handler of the MSR_IA32_DEBUGCTLMSR Documentation/virt/kvm/api.rst | 28 +++ arch/x86/events/core.c | 26 ++- arch/x86/events/intel/core.c | 102 ++++++---- arch/x86/events/intel/lbr.c | 56 +++++- arch/x86/events/perf_event.h | 18 +- arch/x86/include/asm/kvm_host.h | 14 ++ arch/x86/include/asm/perf_event.h | 28 ++- arch/x86/kvm/pmu.c | 27 ++- arch/x86/kvm/pmu.h | 17 +- arch/x86/kvm/svm/pmu.c | 7 +- arch/x86/kvm/vmx/capabilities.h | 15 ++ arch/x86/kvm/vmx/pmu_intel.c | 301 ++++++++++++++++++++++++++++-- arch/x86/kvm/vmx/vmx.c | 11 +- arch/x86/kvm/vmx/vmx.h | 2 + arch/x86/kvm/x86.c | 34 ++-- include/linux/perf_event.h | 7 + include/uapi/linux/kvm.h | 1 + kernel/events/core.c | 7 - 18 files changed, 603 insertions(+), 98 deletions(-) -- 2.21.1