Received: by 2002:a05:7412:f589:b0:e2:908c:2ebd with SMTP id eh9csp926004rdb; Wed, 1 Nov 2023 06:52:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFmCnJBTu7IibTJRuiwqfd98OUKRDMjIEt69CyOE2TQVn03zbltcvk4FuB4SIX4yp0up5YB X-Received: by 2002:a17:90b:1286:b0:280:3370:edb5 with SMTP id fw6-20020a17090b128600b002803370edb5mr7676242pjb.3.1698846733897; Wed, 01 Nov 2023 06:52:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698846733; cv=none; d=google.com; s=arc-20160816; b=nQLoxwzxpPgVHeqo8nn5RCedWhoy3gPct60Zp7ZYumOWEQIAd1DYqtAIWBJI2j0pv3 laDKlE1b1wA3FaDkMPR9Ep9zIsYIn00ENMxD0c1eNHMtMJ6AGBKbFTEIJhMbXWyZuVZO YpCoNJwwIQQp0QlYFUYXXBQGnMer0zTX/nIsf7882hOSXQPrcYjtt82QrqDbD3y1axXL Q4ENPmoxsbkRtgH3+t8EkxTFBZFihixQtiqbh8dGoTvbQ13VlvtQhG6LZx6fqnsj/bkQ I9XEpJmW8uHJTZlB7AchXg0F5bKDpVunYzsvJFPCJYQlbsp9kWtmm3aGB5ynMmjYiuLw AEpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=jZ0ESO45xP9Re2RYSdc1lXxQpbpNR0jHdnjy0Y8OKJ4=; fh=mJnO7TKKRBPYb5XG9yA4mxTP1Cj9RiyrzfO61w/E9ok=; b=SIJ+rYNSFmXd9bRXxTIKUD3+UBL4cx+Amg0WVkqShUU2HHEy8bVgUEEHxrluE5SETr R8OXt46BvG03zandqg6FwztDuQCfIYH/X2K65GnJ0rkc7+hK0DBPCqFfeuj2H7i8xw0S zSRghlNawkdhn5CsDsuZjgkFFz5q4TRkGldpHxSRU8XQDQvFlSnWcyPp4S0QpaBIfHbE qcH7ei+95MBkYMolUXPCUj+ysvEE1GSh9PeFH0LxxgxTndBx4kyLBvif2GWTSvaoltxf xAHyxx/WOyFNARUx59mvQxGjRd7VjenEQHoDPRVTodoXcfJ1fHtugTgpLAxgOdZo5OWw Eg2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=GhUvrzlP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id a3-20020a17090a688300b0027ce6cd3144si896989pjd.126.2023.11.01.06.52.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Nov 2023 06:52:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=GhUvrzlP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 040D4805DC0E; Wed, 1 Nov 2023 06:52:13 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234120AbjKANwM (ORCPT + 99 others); Wed, 1 Nov 2023 09:52:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231924AbjKANwL (ORCPT ); Wed, 1 Nov 2023 09:52:11 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF8D6C1; Wed, 1 Nov 2023 06:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698846725; x=1730382725; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=tp49IqToCZQkv1OkVu0UUxq8QnfuUEUZdkCjxQoX4qw=; b=GhUvrzlPdceKTV+3rwkCsKLgaddAZRkEUnP2oL//k1STmLHjU57U/Xds +XuHoAWkqKxvRjCDD5iTLNMzQ6lyd5XXKpNsafYUv4betvKllzH/L7VDI X/XyZhkrfInQtnA46OurHaEkLpTs2Jj6hTi6RDqhteUdXGK6+5lu2j6zg gZzMHgvx3/NdFN/94DZugt0H/Nw17jQB7pjAnn4dt7FQnaCdbhmx9tABk BQc6b+8FFwZuLwGRjf8x6ASEc8GCDJ+NpbKj9kwMa4ogC5MQLhNZNTD2g o5LqWHx9NXeqiRMM5IfMNzfkHyq5iu6KOmuEoTO00WznKbzGSzWLRC467 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10881"; a="387377508" X-IronPort-AV: E=Sophos;i="6.03,268,1694761200"; d="scan'208";a="387377508" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2023 06:52:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10881"; a="710795430" X-IronPort-AV: E=Sophos;i="6.03,268,1694761200"; d="scan'208";a="710795430" Received: from linux.intel.com ([10.54.29.200]) by orsmga003.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2023 06:52:02 -0700 Received: from [10.212.28.1] (kliang2-mobl1.ccr.corp.intel.com [10.212.28.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by linux.intel.com (Postfix) with ESMTPS id D727E580E3D; Wed, 1 Nov 2023 06:52:00 -0700 (PDT) Message-ID: Date: Wed, 1 Nov 2023 09:51:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [kvm-unit-tests Patch v2 4/5] x86: pmu: Support validation for Intel PMU fixed counter 3 Content-Language: en-US To: "Mi, Dapeng" , Jim Mattson Cc: Sean Christopherson , Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Zhenyu Wang , Zhang Xiong , Mingwei Zhang , Like Xu , Dapeng Mi References: <20231031092921.2885109-1-dapeng1.mi@linux.intel.com> <20231031092921.2885109-5-dapeng1.mi@linux.intel.com> <28796dd3-ac4e-4a38-b9e1-f79533b2a798@linux.intel.com> From: "Liang, Kan" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 01 Nov 2023 06:52:13 -0700 (PDT) On 2023-10-31 11:57 p.m., Mi, Dapeng wrote: > > On 11/1/2023 11:24 AM, Jim Mattson wrote: >> On Tue, Oct 31, 2023 at 8:16 PM Mi, Dapeng >> wrote: >>> >>> On 11/1/2023 10:47 AM, Jim Mattson wrote: >>>> On Tue, Oct 31, 2023 at 7:33 PM Mi, Dapeng >>>> wrote: >>>>> On 11/1/2023 2:47 AM, Jim Mattson wrote: >>>>>> On Tue, Oct 31, 2023 at 2:22 AM Dapeng Mi >>>>>> wrote: >>>>>>> Intel CPUs, like Sapphire Rapids, introduces a new fixed counter >>>>>>> (fixed counter 3) to counter/sample topdown.slots event, but current >>>>>>> code still doesn't cover this new fixed counter. >>>>>>> >>>>>>> So this patch adds code to validate this new fixed counter can count >>>>>>> slots event correctly. >>>>>> I'm not convinced that this actually validates anything. >>>>>> >>>>>> Suppose, for example, that KVM used fixed counter 1 when the guest >>>>>> asked for fixed counter 3. Wouldn't this test still pass? >>>>> Per my understanding, as long as the KVM returns a valid count in the >>>>> reasonable count range, we can think KVM works correctly. We don't >>>>> need >>>>> to entangle on how KVM really uses the HW, it could be impossible and >>>>> unnecessary. >>>> Now, I see how the Pentium FDIV bug escaped notice. Hey, the numbers >>>> are in a reasonable range. What's everyone upset about? >>>> >>>>> Yeah, currently the predefined valid count range may be some kind of >>>>> loose since I want to cover as much as hardwares and avoid to cause >>>>> regression. Especially after introducing the random jump and clflush >>>>> instructions, the cycles and slots become much more hard to predict. >>>>> Maybe we can have a comparable restricted count range in the initial >>>>> change, and we can loosen the restriction then if we encounter a >>>>> failure >>>>> on some specific hardware. do you think it's better? Thanks. >>>> I think the test is essentially useless, and should probably just be >>>> deleted, so that it doesn't give a false sense of confidence. >>> IMO, I can't say the tests are totally useless. Yes,  passing the tests >>> doesn't mean the KVM vPMU must work correctly, but we can say there is >>> something probably wrong if it fails to pass these tests. Considering >>> the hardware differences, it's impossible to set an exact value for >>> these events in advance and it seems there is no better method to verify >>> the PMC count as well. I still prefer to keep these tests until we have >>> a better method to verify the accuracy of the PMC count. >> If it's impossible to set an exact value for these events in advance, >> how does Intel validate the hardware PMU? > > > I have no much idea how HW team validates the PMU functionality. But per > my gotten information, they could have some very tiny benchmarks with a > fixed pattern and run them on a certain scenario, so they can expect an > very accurate count value. But this is different with our case, a real > program is executed on a real system (probably shared with other > programs), the events count is impacted by too much hardware/software > factors, such as cache contention, it's hard to predict a single > accurate count in advance. > Yes, there are many factors could impact the value of the microbenchmarks. I don't think there is a universal benchmark for all generations and all configurations. Thanks, Kan > Anyway, it's only my guess about the ways of hardware validation, still > add Kan to get more information. > > Hi Kan, > > Do you have more information about how HW team to validate the PMC count > accuracy? Thanks. > >