Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp3182507ioa; Mon, 25 Apr 2022 20:36:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMTA70P85YjFrY1dZD9MEhQocVIuPzb22APsPs8RwegI6OhkO2gZlSaAY6QZteYTeBKKT9 X-Received: by 2002:a17:90a:5b09:b0:1cd:b3d3:a3f3 with SMTP id o9-20020a17090a5b0900b001cdb3d3a3f3mr24703255pji.9.1650944172576; Mon, 25 Apr 2022 20:36:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650944172; cv=none; d=google.com; s=arc-20160816; b=NDbx4BfBq7uh7e2dfWasBV1SRd62aNHc0gFIIKU8MvxhP2wY5sz0bhOTovGsuWQSec f/fhlzTUHJ9BwPaRTbPKKOyxM3ZeJZQNBuALsDpeY7xDLm7jsyqAkB+DRgGMVqNKRgbR BbK33jtPYowggsnXnI1P/L31pnMYsjgFg7WhrmHtvu/T2mmrA466wI9axjEEukXsObt9 r4rkQLh1sQMm88gsEwAN49E/Ob1iJOhOmKqFScKDM3m5ns2BS4t5wQRbmRaCAPkzgZKN pwbH8N8+rt16uRjNkpDWYgAcfvbqot42SZHxV88WlIxKZtO5HBy04S6D0D4LdnTP/5v5 SDdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=ZUDdu1OQnuiL9GvFQHLzieqdApEYcfcerAmFX1ae7Fo=; b=zToExYLKy1dlcsR4s1ojNB938rTN534hLvZmqEYqCxIAJbazIz+b3puPOUV4xaftHc Ac/AMj3hzH1cOsjh1F1ebYZzaK8D5i4eWwrjkmyfWvMs37Xo/dkWQ+/8PXx/0/TfxoNE pf6Dt9sBwDCR4uF3XPEMXcP4SVmw/wb79Lfu6FxCG4E+HnCf4/PHzjhVvNkegWFz58hB l0uOlKSt00/ahfaHXb1A2C45CJlMC25R+tyA+LTH0ZaZ4DkAv0TmpTALX02P7fx6m7LA KDgLQkBbGkYDQcE2lhv5tlZL3H3IVMVuGNbCiUVHIUK+uXXclylehBY+bgBjA8o9nWWg cetw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="kOy/628P"; dkim=neutral (no key) header.i=@linutronix.de header.b=rWgCcD6e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u2-20020a63ef02000000b003aa4823f304si18624615pgh.267.2022.04.25.20.35.56; Mon, 25 Apr 2022 20:36:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="kOy/628P"; dkim=neutral (no key) header.i=@linutronix.de header.b=rWgCcD6e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243728AbiDYRJG (ORCPT + 99 others); Mon, 25 Apr 2022 13:09:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243722AbiDYRJF (ORCPT ); Mon, 25 Apr 2022 13:09:05 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7948038DA1; Mon, 25 Apr 2022 10:06:00 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1650906359; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZUDdu1OQnuiL9GvFQHLzieqdApEYcfcerAmFX1ae7Fo=; b=kOy/628PH7EV8vd8Bt7kZYGVV4HH2pzB4IOTaqLluAxvnHwNnpQgoIs22zk31UBsLyiO+g pawUq2PFZuAhwQYxXo2cs7jipQTA4E3eFOYp8u3t/RoivhkrCf5YorU/t3tH5W4NX/IpTm TKM/NYt8SjOfKI3TzCEp1ds+AU0Iw8xTIbAI4UfR0iawo9YEe4k+ML9D4Z8QR+Ylv2KQM2 o5tkv5qW+yvlsjcCEu/7ahiIBuqOyLV83Mxe1aXMquFFyuYKauKIey7Gb0RkvSeywP3pZD 6+F5lyl9VUiubCZbFwfoOUZ/ZEpARHDC4VKKOw6F/pPiB10jkkCjW4jC2oyG5A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1650906359; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZUDdu1OQnuiL9GvFQHLzieqdApEYcfcerAmFX1ae7Fo=; b=rWgCcD6eod8vPhzNBba08C1rj2XHbFC5P7XdDbrtkk5CwN0PDscGntrk8gXPB4CyWzdoyQ YnRFHLfe4Mhyn7AQ== To: Adrian Hunter , Peter Zijlstra Cc: Alexander Shishkin , Arnaldo Carvalho de Melo , Jiri Olsa , "linux-kernel@vger.kernel.org" , Ingo Molnar , Borislav Petkov , Dave Hansen , "x86@kernel.org" , "kvm@vger.kernel.org" , H Peter Anvin , Mathieu Poirier , Suzuki K Poulose , Leo Yan , "jgross@suse.com" , "sdeep@vmware.com" , "pv-drivers@vmware.com" , "pbonzini@redhat.com" , "seanjc@google.com" , "kys@microsoft.com" , "sthemmin@microsoft.com" , "virtualization@lists.linux-foundation.org" , "Andrew.Cooper3@citrix.com" , "Hall, Christopher S" Subject: Re: [PATCH V2 03/11] perf/x86: Add support for TSC in nanoseconds as a perf event clock In-Reply-To: References: <20220214110914.268126-1-adrian.hunter@intel.com> <20220214110914.268126-4-adrian.hunter@intel.com> <853ce127-25f0-d0fe-1d8f-0b0dd4f3ce71@intel.com> <30383f92-59cb-2875-1e1b-ff1a0eacd235@intel.com> <013b5425-2a60-e4d4-b846-444a576f2b28@intel.com> <6f07a7d4e1ad4440bf6c502c8cb6c2ed@intel.com> <50fd2671-6070-0eba-ea68-9df9b79ccac3@intel.com> <87ilqx33vk.ffs@tglx> Date: Mon, 25 Apr 2022 19:05:58 +0200 Message-ID: <87fsm114ax.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS 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 On Mon, Apr 25 2022 at 16:15, Adrian Hunter wrote: > On 25/04/22 12:32, Thomas Gleixner wrote: >> It's hillarious, that we still cling to this pvclock abomination, while >> we happily expose TSC deadline timer to the guest. TSC virt scaling was >> implemented in hardware for a reason. > > So you are talking about changing VMX TCS Offset on every VM-Entry to try to hide > the time jumps when the VM is scheduled out? Or neglect that and just let the time > jumps happen? > > If changing VMX TCS Offset, how can TSC be kept consistent between each VCPU i.e. > wouldn't that mean each VCPU has to have the same VMX TSC Offset? Obviously so. That's the only thing which makes sense, no? Thanks, tglx