Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp2270473pxm; Fri, 4 Mar 2022 12:47:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJw1f183CvwYhItGIvvLh8D0AY1U2VkK9We8OMYENcyTL7hwkY5pey9GhS5Unf+IaLMHPIeb X-Received: by 2002:a17:903:2310:b0:150:27f1:e94 with SMTP id d16-20020a170903231000b0015027f10e94mr250522plh.96.1646426827275; Fri, 04 Mar 2022 12:47:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646426827; cv=none; d=google.com; s=arc-20160816; b=p6IZ3K4TaP/96+JDz31EavwrhX0tBjHl47TtjzvwUbGPtXd41IOO/GTVX6pcsy9833 6wQvd/wtgN4DETg57KQAOq28yCVQqbtBU2Z5mhwdTshsLD3QhBLoS+jH3OS1FVhaLhMo TWLl0Ml0O7MKDLyvh6B6xYzF4VLvvDXyShlT8ivPMoBITkPZHPhwkAB/KjsUj0xsRuBN SX7WwROR6SU4vDeituwS5GjbDAdJz1krQZvgdP98iuApK4FUZFyQs1mz80BE9TP7tCj4 3aUd4uFuspSfUUUMYSxkNbn1x/FsU7HAbdAKQ9huAjTm6vWEoApv79RcRSkev/cHfcTM I0qg== 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 :organization:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:dkim-signature; bh=OmEqo/0uZA3IBrgdR5szk5V+qgfJ4AodsnhAr0VetD4=; b=0Lc0Dwc9Hq6qsPZeXsomQ3Q5YmM/X2odx3qdCn7PIYOChVqu1Nsn+AR6jxq//3Huly WhdD/oSVHUuia0jbMKZMCb3jFi9EkB+FUMKLl1DeZ1+hzCD4o6WbeJp0Dr8lvyei3pIb apM/YGSPPQEnd6ZT2KPrasEhnaSY7ioQVw4InCqoeujN3Uwv9ZuxczwhcC/tGjoEfRVR TV0LRV9eDWMYQJaA6rq3tJzoCfJgx6bsOaUc0S3l8/cGBQTVJvo8+SBgdYcrEiyGSdww qlc8c6AowIjN9IvfdbtPSBFRloSsCPzMcMBlKsGhK9jF4CrrmzUvBIf4Vr0LtTvXVzF0 Zm1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=O4vH4eOH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id bf17-20020a656d11000000b00372f2b97fb4si5968780pgb.693.2022.03.04.12.47.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Mar 2022 12:47:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=O4vH4eOH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 34C7826E2A6; Fri, 4 Mar 2022 11:47:51 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241656AbiCDS2n (ORCPT + 99 others); Fri, 4 Mar 2022 13:28:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241639AbiCDS2j (ORCPT ); Fri, 4 Mar 2022 13:28:39 -0500 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B36224DF46; Fri, 4 Mar 2022 10:27:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646418470; x=1677954470; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=DWG7yBjX/SsVDq1FNBzX1eDw1t6YL3NhhuMKSucJuqU=; b=O4vH4eOHEJQ7lchSM0g0Gr3Fu9772Hi3MWYOc8quI/8yJRWiqvfRB7W0 nxk7/fl7yKWKa3S+WkqfQQqcOBUtOtibh2v5CrVUBFcmji2QCiSmWqllW 9wrlz1ue5RSQaPQr2hmY+ver7/ZOby0cydtIqLmVUaDY+68BCdJw63v8G AnBtEbaF1ZXgk5t7zcKwMg031MtZbAs9SCrKyg2cvpTXdAPpadO+hXkX4 pLS0dtmjI3z3s/9RgSOKf+KXfWX/jbUJX/Pz6SO5QS91n5LenRVKjlrVw PoiSIY8E2KS0CM6FkzfbFwkrfYNRXQZD/KMs9X5uUgfsOr5UfXLH9lDTf Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10276"; a="253969031" X-IronPort-AV: E=Sophos;i="5.90,155,1643702400"; d="scan'208";a="253969031" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2022 10:27:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,155,1643702400"; d="scan'208";a="552317837" Received: from ahunter-desktop.fi.intel.com (HELO [10.237.72.92]) ([10.237.72.92]) by orsmga008.jf.intel.com with ESMTP; 04 Mar 2022 10:27:46 -0800 Message-ID: <853ce127-25f0-d0fe-1d8f-0b0dd4f3ce71@intel.com> Date: Fri, 4 Mar 2022 20:27:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.0 Subject: Re: [PATCH V2 03/11] perf/x86: Add support for TSC in nanoseconds as a perf event clock Content-Language: en-US To: Peter Zijlstra Cc: Alexander Shishkin , Arnaldo Carvalho de Melo , Jiri Olsa , linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, kvm@vger.kernel.org, H Peter Anvin , Mathieu Poirier , Suzuki K Poulose , Leo Yan References: <20220214110914.268126-1-adrian.hunter@intel.com> <20220214110914.268126-4-adrian.hunter@intel.com> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 On 04/03/2022 15:41, Peter Zijlstra wrote: > On Mon, Feb 14, 2022 at 01:09:06PM +0200, Adrian Hunter wrote: >> Currently, when Intel PT is used within a VM guest, it is not possible to >> make use of TSC because perf clock is subject to paravirtualization. > > Yeah, so how much of that still makes sense, or ever did? AFAIK the > whole pv_clock thing is utter crazy. Should we not fix that instead? Presumably pv_clock must work with different host operating systems. Similarly, KVM must work with different guest operating systems. Perhaps I'm wrong, but I imagine re-engineering time virtualization might be a pretty big deal, far exceeding the scope of these patches. While it is not something that I really need, it is also not obvious that the virtualization people would see any benefit. My primary goal is to be able to make a trace covering the host and (Linux) guests. Intel PT can do that. It can trace straight through VM-Entries/Exits, politely noting them on the way past. Perf tools already supports decoding that, but only for tracing the kernel because it needs more information (so-called side-band events) to decode guest user space. The simplest way to get that is to run perf inside the guests to capture the side-band events, and then inject them into the host perf.data file during post processing. That, however, requires a clock that works for both host and guests. TSC is suitable because KVM largely leaves it alone, except for VMX TSC Offset and Scaling, but that has to be dealt with anyway because it also affects the Intel PT trace.