Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3671958pxf; Mon, 15 Mar 2021 15:42:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyAt6ESIBIO7Bnk5T9qAC+NwYjJ2amn9Okp78qjyUd2+5w6AgDrAH9hFVdLBYCHqVuNcsrC X-Received: by 2002:a17:906:7d7:: with SMTP id m23mr26441167ejc.205.1615848127141; Mon, 15 Mar 2021 15:42:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615848127; cv=none; d=google.com; s=arc-20160816; b=MDOzyb7BJ39JrLXHWtJfv3JtEsxKILzvLDXCfowSTMa8zb+mBivW7tOCGSyzIarbNc 4CazTe0r9ycOLcIPkZ+YevNcfXpYkRq87dK479kI/ByVmhA9Xvmhu0C3KZaQgdv7kF8M 0HZBBuKFLvj9Sa7hvtMosHF69xOYKMSJVdaG1zWei4QRVSfC0OHFjoJdRUS+0sYb4HLZ NKhy0v2zFJpVcbl2nZP8HN171Ow0TnftruLnvyuuOeDSzhuILfTVRmxIwoh7cPVerov6 aZI9Sl4CpqPA553wzn+i+a6KcozP26pwQ4BEtxdjt2DW9n0vaZEXDj086rTH+Oc/hPgA WSmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=hnb0tSx4kJbvP2pKtgWjdH/DYz7FC6HDufABJGRGyOw=; b=ASGdD+0PcOiMOI4gjMbTFxhNT11ERgsUq9hu2rF7mX0M6i7b75nJSUOZRCXvfNZT6b BCdfe2co6SoZzkjraoc8RlSkRaU1m8wugzGwFjhCaaJSGBEpBd1Ae7thNUzE+QHhBkfa irO3lb1Nw+nnvWDfZb2FvQ9Xkge24Mp7LrMvcz2S1xXuWjiZFsnMo0k3IlrpRPe9aIu1 Gr2xu3seZGwGAaw8tlhmszx6xgCU7tgmV5RYddJGPd45fuDpZN4/x40yepqBy0MWTLrc cH0m4UFKNajS42sU4UvsCvri9TEltCRs1liOErVX4lcQb7ByWS8hHEw6x7F3l63UoXGx VnMA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=vmware.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u4si12142162ejz.522.2021.03.15.15.41.42; Mon, 15 Mar 2021 15:42:07 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=vmware.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232005AbhCOWkC convert rfc822-to-8bit (ORCPT + 99 others); Mon, 15 Mar 2021 18:40:02 -0400 Received: from ex13-edg-ou-001.vmware.com ([208.91.0.189]:1445 "EHLO EX13-EDG-OU-001.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231377AbhCOWjp (ORCPT ); Mon, 15 Mar 2021 18:39:45 -0400 X-Greylist: delayed 901 seconds by postgrey-1.27 at vger.kernel.org; Mon, 15 Mar 2021 18:39:45 EDT Received: from sc9-mailhost3.vmware.com (10.113.161.73) by EX13-EDG-OU-001.vmware.com (10.113.208.155) with Microsoft SMTP Server id 15.0.1156.6; Mon, 15 Mar 2021 15:24:43 -0700 Received: from [10.200.196.160] (unknown [10.200.196.160]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 323722050D; Mon, 15 Mar 2021 15:24:44 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: [PATCH] x86/vmware: avoid TSC recalibration From: Alexey Makhalov In-Reply-To: <87im8bildr.fsf@vitty.brq.redhat.com> Date: Mon, 15 Mar 2021 15:24:43 -0700 CC: , , "H . Peter Anvin" , Borislav Petkov , , , , Content-Transfer-Encoding: 8BIT Message-ID: <84F586C5-EECE-4EE5-8988-64D8E0325D7A@vmware.com> References: <20210105004752.131069-1-amakhalov@vmware.com> <87im8bildr.fsf@vitty.brq.redhat.com> To: Vitaly Kuznetsov X-Mailer: Apple Mail (2.3654.60.0.2.21) Received-SPF: None (EX13-EDG-OU-001.vmware.com: amakhalov@vmware.com does not designate permitted sender hosts) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vitaly, I believe, it is responsibility of each guest code to set X86_FEATURE_TSC_KNOWN_FREQ cap. Regarding VMware guest, there is a case where vmware_tsc_khz is zero (not provided by hypervisor) and TSC frequency should be calculated. Sorry for late response. Regards, —Alexey > On Jan 5, 2021, at 5:06 AM, Vitaly Kuznetsov wrote: > > Alexey Makhalov writes: > >> When TSC frequency is known (retrieved from hypervisor), we should skip >> TSC refined calibration by setting X86_FEATURE_TSC_KNOWN_FREQ. >> >> Signed-off-by: Alexey Makhalov >> --- >> arch/x86/kernel/cpu/vmware.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c >> index c6ede3b3d302..83164110ccc5 100644 >> --- a/arch/x86/kernel/cpu/vmware.c >> +++ b/arch/x86/kernel/cpu/vmware.c >> @@ -378,6 +378,8 @@ static void __init vmware_set_capabilities(void) >> { >> setup_force_cpu_cap(X86_FEATURE_CONSTANT_TSC); >> setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE); >> + if (vmware_tsc_khz) >> + setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); >> if (vmware_hypercall_mode == CPUID_VMWARE_FEATURES_ECX_VMCALL) >> setup_force_cpu_cap(X86_FEATURE_VMCALL); >> else if (vmware_hypercall_mode == CPUID_VMWARE_FEATURES_ECX_VMMCALL) > > The same trick is being used in Xen/Jailhouse/KVM code already and > Hyper-V overwrites x86_platform.calibrate_tsc/x86_platform.calibrate_cpu > hooks to basically achive the same goal. Should we maybe introduce a > flag in 'struct hypervisor_x86' or something like that to unify all > this? > > Just a suggestion. > > -- > Vitaly