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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 29D35C433DB for ; Wed, 20 Jan 2021 01:15:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D7E6A23109 for ; Wed, 20 Jan 2021 01:15:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730512AbhATBPC (ORCPT ); Tue, 19 Jan 2021 20:15:02 -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-Google-Smtp-Source: ABdhPJzF25cY4pSdzS61sqXxO/zBeDkhnV56fO5UhbvMZOHz8G4oGxVj19n7F7u1XHWZY1uCLCvFXQ== 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 :-)