Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3207374pxb; Tue, 19 Jan 2021 17:18:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJy51/rr+oYFZzrEq/pSLB5OyLS9+EY9dJE40DO97CJZwtlFAhDmUtvnuf+b+UZIyFaw2p92 X-Received: by 2002:a17:906:2e0d:: with SMTP id n13mr4441036eji.554.1611105503349; Tue, 19 Jan 2021 17:18:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611105503; cv=none; d=google.com; s=arc-20160816; b=PHTRld3LLR8kJNoEKG3hPYapwrViQ42CRuuMhV35xL2BYbSPNXKxBTj/glWJUb5Z5E Y5eghxNLmbxu6st71NnSc7twQYMb1yxilv53tPw+xq9Agd9L6n015wdjqQYZvKYeE2yw +KR5fVVsFQ/MfMY5OT+e2LvHF7lB6PEVGMQeTjH/pbTn5BJkFaEs34B0/U/+KVPv4yZl gkPyPTwr9z6SQ3U/lplmisQ5YVfJvhupNJqMirqTgSFgsPqV50tVEIRsGm5dl4bsR9jx Trv7WnGAtmRTUqTiJr2mj5UKgaYYsTDhkJtYwg/6Etx1fMqGrvhhWiBLY8M0KYmsCr4K T2Ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=LbrB+4hBFfY1b4S9nQZrJqW6y4BpWyRafcJJN86RQm0=; b=qalsFjsoong+EM8i/I+eULSOz4J1DOWcMsX8VvJIbSKGV9T9DGeWKQASpIHB1Ede8b ide9Z/Wb7T17GOwqk+Y3sDGSqi56OTEJfVP0NbGsog4d/UXf7CbcGbFAetwYE+Chnqy5 3jCRcX0AvDn4V/ztVD26tX6J+L+RzFnljo5npXBTeuY73fHDK0W/u8ynPUR/s582mpma /Y3OXGWzxwWk3CoxypH0BanoJSzmX5rXYuYlVwnizMkQhcRtLmnVivxWHq/RjOOx+J6a DJ6/J+T63ISoZUy863b3tZrlCMjaYuQEnwYksGILV7+QL4jXv7OSI/7tVuDl0fKCQpJF QVrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ZBwz00YW; 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 y22si179316ejc.25.2021.01.19.17.17.58; Tue, 19 Jan 2021 17:18:23 -0800 (PST) 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=ZBwz00YW; 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 S1729720AbhATBOl (ORCPT + 99 others); Tue, 19 Jan 2021 20:14:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729161AbhATBOf (ORCPT ); Tue, 19 Jan 2021 20:14:35 -0500 Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40AC9C061575 for ; Tue, 19 Jan 2021 17:13:55 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id m6so13471132pfk.1 for ; Tue, 19 Jan 2021 17:13:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=LbrB+4hBFfY1b4S9nQZrJqW6y4BpWyRafcJJN86RQm0=; b=ZBwz00YWmDJicFydsf3OnyNkQhb1TYHGNQwSv0LX7h1Z0uHe0PENX+xlbfUIL5C1Kr 8K/fMxTwhSXNVSBOx58wsj2dZI89AhRrg4VtqgoYUnCyE4ggWKxgMSTzkNkWy8JOXCve dPBNvbkur0z+AW/hXNLkjbo6VGlS1N/+aG9JIg4B5+P/Z5hwYuvxI8ego1KzUyY8tVyN U5nkBpCxUqp5EoJzZEf9CJbjm+moSqToMdd8z14G90nnzPiAyiLq93lixACACRpS2U/t 1/ertp/SYCHvOvnSiUh1oi9oM6085eRWyQra/b9jjfkU06WSjLiUDnKKHcutlw4lzNbs D6Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=LbrB+4hBFfY1b4S9nQZrJqW6y4BpWyRafcJJN86RQm0=; b=hjSXYratA0cCcS/NJukVR4tNRR3iJbpQVxycVXKMCz4qG0ncDBNDmAY4KXk+vAFC4s QmJB+Ak4kg96j89TJ4SHWXPVhF3S5miHDOq+7zUiyM0vP47PdlsnHeE9Ws0wXS6TOtTc l+rUShtSrLytZIyik14c0o2PnP5AeSFSvSxZ+br8lzPvwIHTE1XA6Nz59WihyLng18a7 1nVQLyGwe9dD5BOB4Eokl5GhcF4uJ+m+z08qr/ewBjmXkIzAkX3m+/LnOQYvfaaKrsdt 4CQtaD5pNGQyZVQu1FYZK178XL/SaIUmebxpOkTDp2I6yPO3LdRglG9jnGTncE8hL44/ FoKQ== X-Gm-Message-State: AOAM530c/iWYUq1yphTO81yVrlStpUcMls2fEJJpbRe3hOkRZRpSZl60 dxfijEtLWwGGRf3BPj/O9dH+Nw== X-Received: by 2002:a62:1516:0:b029:1b6:8e43:dad7 with SMTP id 22-20020a6215160000b02901b68e43dad7mr6916153pfv.64.1611105234641; Tue, 19 Jan 2021 17:13:54 -0800 (PST) Received: from google.com ([2620:15c:f:10:1ea0:b8ff:fe73:50f5]) by smtp.gmail.com with ESMTPSA id g201sm307734pfb.81.2021.01.19.17.13.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Jan 2021 17:13:53 -0800 (PST) Date: Tue, 19 Jan 2021 17:13:47 -0800 From: Sean Christopherson To: "Xu, Like" Cc: Paolo Bonzini , Stephane Eranian , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Like Xu Subject: Re: [PATCH] KVM: x86/pmu: Fix HW_REF_CPU_CYCLES event pseudo-encoding in intel_arch_events[] Message-ID: References: <20201230081916.63417-1-like.xu@linux.intel.com> <1ff5381c-3057-7ca2-6f62-bbdcefd8e427@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 18, 2021, Xu, Like wrote: > On 2021/1/16 1:30, Sean Christopherson wrote: > > On Fri, Jan 15, 2021, Like Xu wrote: > > > > diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c > > > > index a886a47daebd..013e8d253dfa 100644 > > > > --- a/arch/x86/kvm/vmx/pmu_intel.c > > > > +++ b/arch/x86/kvm/vmx/pmu_intel.c > > > > @@ -29,7 +29,7 @@ static struct kvm_event_hw_type_mapping intel_arch_events[] = { > > > > [4] = { 0x2e, 0x41, PERF_COUNT_HW_CACHE_MISSES }, > > > > [5] = { 0xc4, 0x00, PERF_COUNT_HW_BRANCH_INSTRUCTIONS }, > > > > [6] = { 0xc5, 0x00, PERF_COUNT_HW_BRANCH_MISSES }, > > > > - [7] = { 0x00, 0x30, PERF_COUNT_HW_REF_CPU_CYCLES }, > > > > + [7] = { 0x00, 0x03, PERF_COUNT_HW_REF_CPU_CYCLES }, > > In a follow up patch, would it be sane/appropriate to define these magic numbers > > in asm/perf_event.h and share them between intel_perfmon_event_map and > > intel_arch_events? Without this patch, it's not at all obvious that these are > > intended to align with the Core (arch?) event definitions. > > The asm/perf_event.h is x86 generic and svm has a amd_perfmon_event_map. Ugh, duh. > How about adding an interface similar to perf_get_x86_pmu_capability() > so that we can use magic numbers directly from the host perf ? > (it looks we may have a performance drop, compared to static array) Alternatively, you could use the existing event_map() to generate intel_arch_events[] during init. That might be easier since, AFAICT, the array indices have different meaning for KVM than for perf. Honestly, unless there are going to be new arch events in the near-ish future, it may not be worth the effort at this point. Until now, the above table hadn't changed in over five years. I.e. don't put a bunch of effort into this unless you want to :-)