Message ID | 20231030063652.68675-14-nikunj@amd.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:d641:0:b0:403:3b70:6f57 with SMTP id cy1csp2018733vqb; Sun, 29 Oct 2023 23:40:28 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHyoPuZ38cgOnd0N81Jlh23RFJoYYGLnidYWl11A7rZRbuo+fJWg8s51o62PfrxvKw4nLbs X-Received: by 2002:a17:90a:b78b:b0:27d:c35:7f3 with SMTP id m11-20020a17090ab78b00b0027d0c3507f3mr6399253pjr.8.1698648028341; Sun, 29 Oct 2023 23:40:28 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1698648028; cv=pass; d=google.com; s=arc-20160816; b=it0gkuP1xgcWUAaA01tk8fwQnhsWm9tqn2AQ0hTiih6gRelrcYaBSRIzFXa23cBCFB 7MfUbw7t/ov+dJ+ak09iKLb3ebk+/5z4QvlKKhOYVJDBRGOJ8gdbnjvYrRzcq5A8cH93 8okUDDqQdw8Ku11PEbtufwcAHzNt/S9jTaMQ8IN3gAYjZe0WAn7M3u4sEXKMSFF2jEZH gD+RNfR8ku9UOxPtcskGzR5VzyoJt5zY7uNqRkYe3Z4YloFpQq9YUu7c5z7Oh+Srr8hx 5jf/tOF+AeDTKElBF1s7ZIopXduAo1y8lF46BmPwXmzq7zNnjEqhqlqAhkQvyiFme4wX PjKQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ILqZIkS9mKKLRTC/aYbD3HD/UriMPsQavoeDP1l02pc=; fh=GrBYTfaCmKSBoJ0OQBiloTDpWB/NcGHvBdTqN4MlWVs=; b=O9Y57LsTe2ZKbqneay4aen4d1YuuuqvQXN+xdvjDnsPBmakf6uQxpkNX8+V9A9aPfw UWcS6tZm2fEJb6S/L0SXwjK0tXPPUDS0pgql5hB/LQwxQk0rq++vihqzzbi2qzplcBLX VIBYvrnpw3O4qTbY78vAR/LIzEmVbo/gCfOgTfRTQOOGAQHvvqHIGoDv/tr5TDMeVoDx +loBVpmnscPUHbnm1tbmDpkUakCjc1CEBWPwKQ+deYw+D4wp4phADsc1WCqmYfGcpvD8 BWUN9pwuYEt8JJzbqIACxVh9S/LfhPc94xlYsiP5divZEqV2ilJY/ophRRTKzAGJVyg6 duuw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=HH2zhQyQ; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id i5-20020a17090a974500b00278f5fad9b6si1542239pjw.139.2023.10.29.23.40.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 29 Oct 2023 23:40:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=HH2zhQyQ; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 002208087204; Sun, 29 Oct 2023 23:40:25 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231898AbjJ3Gj3 (ORCPT <rfc822;chrisjones.unixmen@gmail.com> + 32 others); Mon, 30 Oct 2023 02:39:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35618 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232118AbjJ3GjI (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 30 Oct 2023 02:39:08 -0400 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on2089.outbound.protection.outlook.com [40.107.102.89]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D74ABDF; Sun, 29 Oct 2023 23:38:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m8D7RbWzqqDfwxwNZrfLoIGTGBlgYdu00DBrIISNIwFSoFr9HWAs/mYT12ql09hEvE9xxxO3IzRyh3XOEUoK4mIpJeGjRPQ0mxGays2QhyH+4DhuCvEmZQpje7DHiKBeaOkY8r9M5lY1AIOnCaiTxhZrpRxB/OEWuQouLaL21d13V7UHHOFViXWNpRBJn7Vgf/8uuynNaK0sFh2BX7vQCq2WJqydO/FGZpFy+eheTtUialV1xWihvUt9SwAsrMrpMbJ+irB/Czk7/MTnm/MS4x8jFnm4kwRW2R5Lhno+80mbRgpi699vz+zqBMcWsW+AuuN+hDCHhX6E+653HOQKdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ILqZIkS9mKKLRTC/aYbD3HD/UriMPsQavoeDP1l02pc=; b=cJi9nvvO5RObiqd/KfErLhP06lx67ztjvQMBlfn+D86puSJoow1vzUFMg4gWmE/doEX2Xds74byznSfu2n/IXbAudIVk3ayvRBzzvL82ZtqA4NV0gjjlK6jwC2+xkCV7L+5CHKTd2SrPOaKh1TGAixOCWe6Wp7o7EDY5vFZO9JZqAO+Pjgk6wgj0PPrLDTnzDerXY0b54z+6rFinwRo+XWj8cy686eKhu+aDnvZv2hDpyzbd1b28LaKkKpbVdiLxw/ZvRrkk3UQh0wD/iknJf+5MDQuwIHIKwZxwszE17b9WR9hiFgJ848x5shlFhyuRRrvAJ3DMLfj3VwHUtv0ghg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=vger.kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ILqZIkS9mKKLRTC/aYbD3HD/UriMPsQavoeDP1l02pc=; b=HH2zhQyQjQJmcC/BufQOkOpMHG6yv4oPkXXEVZAl07ayjvzJLa7MnZbrPjFe9JhxHZkS26uHjDyHS5Ys25x5HjUPzKt1A2BLscRrTXCz7uyMvav/241w2HK2pZyESHWEvoknVl9rtZZWZ7uDyIXPxOkXqcYbs9pOoOhDTyjf9do= Received: from BL1PR13CA0300.namprd13.prod.outlook.com (2603:10b6:208:2bc::35) by MN6PR12MB8470.namprd12.prod.outlook.com (2603:10b6:208:46d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6933.27; Mon, 30 Oct 2023 06:38:49 +0000 Received: from BL6PEPF0001AB78.namprd02.prod.outlook.com (2603:10b6:208:2bc:cafe::59) by BL1PR13CA0300.outlook.office365.com (2603:10b6:208:2bc::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.14 via Frontend Transport; Mon, 30 Oct 2023 06:38:49 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by BL6PEPF0001AB78.mail.protection.outlook.com (10.167.242.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6933.15 via Frontend Transport; Mon, 30 Oct 2023 06:38:48 +0000 Received: from gomati.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Mon, 30 Oct 2023 01:38:44 -0500 From: Nikunj A Dadhania <nikunj@amd.com> To: <linux-kernel@vger.kernel.org>, <thomas.lendacky@amd.com>, <x86@kernel.org>, <kvm@vger.kernel.org> CC: <bp@alien8.de>, <mingo@redhat.com>, <tglx@linutronix.de>, <dave.hansen@linux.intel.com>, <dionnaglaze@google.com>, <pgonda@google.com>, <seanjc@google.com>, <pbonzini@redhat.com>, <nikunj@amd.com> Subject: [PATCH v5 13/14] x86/tsc: Mark Secure TSC as reliable clocksource Date: Mon, 30 Oct 2023 12:06:51 +0530 Message-ID: <20231030063652.68675-14-nikunj@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231030063652.68675-1-nikunj@amd.com> References: <20231030063652.68675-1-nikunj@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB78:EE_|MN6PR12MB8470:EE_ X-MS-Office365-Filtering-Correlation-Id: 4d0a6e4d-48a4-4428-dae3-08dbd912dfc9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: C8o/5IE+ZRhA/HdMhEAAMTwcW+okMPBeP3X1QvfVK1CzTX94blqazXjKAXGiGurU/zqxEC+s+E5hBlP1iDPlapmldZpjZZHid5Z7+1EnyYPSvRe7W9LDwpaALO/pNSGYuLHJMCSH8fcPTc1zysXmSNVQVOQCL7AW0uGjhnjAnD/8QmJ8311JfgIlSzURdR2YyYKxpAiWR1z2XMVD1nIOhCiZukoTBL7VNDEgcpjEZSAN+ZsM1IZ1pXAKgdpmvowwNckfPmhmLrc8gvRVwjqaPGUBBobQEv5bkbhn5YIkgKMb1hRs8dAEpzPoHyVzmXHgAiRw2Op5tg6qyhlZEz7OtR9TTbZZxyuCacjn65w43ulUz5MB8NG5PeFEy1QC3rXgfsBKTuW62JnNCYdGPi+03nQ3ATC7eVS8dOVzDHrP3+8ZY5h58DJ4WcfmC7U3zrU0u7Ow1Y0QqEVlv2COGuuSJlRKtOetW1A66cv5zAlrop/tneLKBqnMocO3n/ovG4yesp1fv4zMDuncu7KMAz+uICx1OMcHf3Tj1djZLpgfAawO8orC4UjCDa8PPj1CHUGffxvYeobgAIHuuUceK3nrogQxsDouA1rnRqVyCmoZ9EPkv0plGgLfhRyD+INWuIRL4jorNIaVucQSzw5GvJlf8/b4TPWoTDhHnY2p4IFoKEjsFd2CFGnqo3zdLkTKpoQSVB8bQg9aAjqxJrwER6M6qY+fQ9CPKRB/g8oLCJ6CA+wpjhy6dFqdMrfT9PxoStmQks9OPDSW47Z0IPZIglBLDA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(4636009)(376002)(396003)(39860400002)(136003)(346002)(230922051799003)(64100799003)(82310400011)(186009)(1800799009)(451199024)(46966006)(36840700001)(40470700004)(7696005)(6666004)(478600001)(83380400001)(16526019)(47076005)(4744005)(26005)(2616005)(1076003)(336012)(426003)(2906002)(5660300002)(7416002)(41300700001)(54906003)(316002)(70206006)(110136005)(4326008)(8676002)(8936002)(70586007)(36860700001)(36756003)(81166007)(356005)(82740400003)(40480700001)(40460700003)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2023 06:38:48.9775 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4d0a6e4d-48a4-4428-dae3-08dbd912dfc9 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL6PEPF0001AB78.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR12MB8470 X-Spam-Status: No, score=-1.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Sun, 29 Oct 2023 23:40:26 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781161555089120824 X-GMAIL-MSGID: 1781161555089120824 |
Series |
Add Secure TSC support for SNP guests
|
|
Commit Message
Nikunj A. Dadhania
Oct. 30, 2023, 6:36 a.m. UTC
AMD SNP guests may have Secure TSC feature enabled. Secure TSC as
clocksource is wrongly marked as unstable, mark Secure TSC as
reliable.
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
---
arch/x86/kernel/tsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 10/29/23 23:36, Nikunj A Dadhania wrote: ... > diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c > index 15f97c0abc9d..b0a8546d3703 100644 > --- a/arch/x86/kernel/tsc.c > +++ b/arch/x86/kernel/tsc.c > @@ -1241,7 +1241,7 @@ static void __init check_system_tsc_reliable(void) > tsc_clocksource_reliable = 1; > } > #endif > - if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE)) > + if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE) || cc_platform_has(CC_ATTR_GUEST_SECURE_TSC)) > tsc_clocksource_reliable = 1; Why can't you just set X86_FEATURE_TSC_RELIABLE?
On 10/30/2023 10:48 PM, Dave Hansen wrote: > On 10/29/23 23:36, Nikunj A Dadhania wrote: > ... >> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c >> index 15f97c0abc9d..b0a8546d3703 100644 >> --- a/arch/x86/kernel/tsc.c >> +++ b/arch/x86/kernel/tsc.c >> @@ -1241,7 +1241,7 @@ static void __init check_system_tsc_reliable(void) >> tsc_clocksource_reliable = 1; >> } >> #endif >> - if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE)) >> + if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE) || cc_platform_has(CC_ATTR_GUEST_SECURE_TSC)) >> tsc_clocksource_reliable = 1; > > Why can't you just set X86_FEATURE_TSC_RELIABLE? Last time when I tried, I had removed my kvmclock changes and I had set the X86_FEATURE_TSC_RELIABLE similar to Kirill's patch[1], this did not select the SecureTSC. Let me try setting X86_FEATURE_TSC_RELIABLE and retaining my patch for skipping kvmclock. Regards Nikunj 1: https://lore.kernel.org/lkml/20230808162320.27297-1-kirill.shutemov@linux.intel.com/
On Thu, Nov 02, 2023 at 11:23:34AM +0530, Nikunj A. Dadhania wrote: > On 10/30/2023 10:48 PM, Dave Hansen wrote: > > On 10/29/23 23:36, Nikunj A Dadhania wrote: > > ... > >> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c > >> index 15f97c0abc9d..b0a8546d3703 100644 > >> --- a/arch/x86/kernel/tsc.c > >> +++ b/arch/x86/kernel/tsc.c > >> @@ -1241,7 +1241,7 @@ static void __init check_system_tsc_reliable(void) > >> tsc_clocksource_reliable = 1; > >> } > >> #endif > >> - if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE)) > >> + if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE) || cc_platform_has(CC_ATTR_GUEST_SECURE_TSC)) > >> tsc_clocksource_reliable = 1; > > > > Why can't you just set X86_FEATURE_TSC_RELIABLE? > > Last time when I tried, I had removed my kvmclock changes and I had set > the X86_FEATURE_TSC_RELIABLE similar to Kirill's patch[1], this did not > select the SecureTSC. > > Let me try setting X86_FEATURE_TSC_RELIABLE and retaining my patch for > skipping kvmclock. kvmclock lowers its rating if TSC is good enough: if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC) && boot_cpu_has(X86_FEATURE_NONSTOP_TSC) && !check_tsc_unstable()) kvm_clock.rating = 299; Does your TSC meet the requirements?
On 11/2/2023 4:03 PM, Kirill A. Shutemov wrote: > On Thu, Nov 02, 2023 at 11:23:34AM +0530, Nikunj A. Dadhania wrote: >> On 10/30/2023 10:48 PM, Dave Hansen wrote: >>> On 10/29/23 23:36, Nikunj A Dadhania wrote: >>> ... >>>> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c >>>> index 15f97c0abc9d..b0a8546d3703 100644 >>>> --- a/arch/x86/kernel/tsc.c >>>> +++ b/arch/x86/kernel/tsc.c >>>> @@ -1241,7 +1241,7 @@ static void __init check_system_tsc_reliable(void) >>>> tsc_clocksource_reliable = 1; >>>> } >>>> #endif >>>> - if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE)) >>>> + if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE) || cc_platform_has(CC_ATTR_GUEST_SECURE_TSC)) >>>> tsc_clocksource_reliable = 1; >>> >>> Why can't you just set X86_FEATURE_TSC_RELIABLE? >> >> Last time when I tried, I had removed my kvmclock changes and I had set >> the X86_FEATURE_TSC_RELIABLE similar to Kirill's patch[1], this did not >> select the SecureTSC. >> >> Let me try setting X86_FEATURE_TSC_RELIABLE and retaining my patch for >> skipping kvmclock. > > kvmclock lowers its rating if TSC is good enough: > > if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC) && > boot_cpu_has(X86_FEATURE_NONSTOP_TSC) && > !check_tsc_unstable()) > kvm_clock.rating = 299; > > Does your TSC meet the requirements? I have set TscInvariant (bit 8) in CPUID_8000_0007_edx and TSC is set as reliable. With this I see kvm_clock rating being lowered, but kvm-clock is still being picked as clock-source. [ 0.000834] kvmclock_init: lowering kvm_clock rating [ 0.002623] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [ 2.295082] clocksource: Switched to clocksource kvm-clock Regards Nikunj
On 11/2/2023 5:37 PM, Nikunj A. Dadhania wrote: > On 11/2/2023 4:03 PM, Kirill A. Shutemov wrote: >> On Thu, Nov 02, 2023 at 11:23:34AM +0530, Nikunj A. Dadhania wrote: >>> On 10/30/2023 10:48 PM, Dave Hansen wrote: >>>> On 10/29/23 23:36, Nikunj A Dadhania wrote: >>>> ... >>>>> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c >>>>> index 15f97c0abc9d..b0a8546d3703 100644 >>>>> --- a/arch/x86/kernel/tsc.c >>>>> +++ b/arch/x86/kernel/tsc.c >>>>> @@ -1241,7 +1241,7 @@ static void __init check_system_tsc_reliable(void) >>>>> tsc_clocksource_reliable = 1; >>>>> } >>>>> #endif >>>>> - if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE)) >>>>> + if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE) || cc_platform_has(CC_ATTR_GUEST_SECURE_TSC)) >>>>> tsc_clocksource_reliable = 1; >>>> >>>> Why can't you just set X86_FEATURE_TSC_RELIABLE? >>> >>> Last time when I tried, I had removed my kvmclock changes and I had set >>> the X86_FEATURE_TSC_RELIABLE similar to Kirill's patch[1], this did not >>> select the SecureTSC. >>> >>> Let me try setting X86_FEATURE_TSC_RELIABLE and retaining my patch for >>> skipping kvmclock. >> >> kvmclock lowers its rating if TSC is good enough: >> >> if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC) && >> boot_cpu_has(X86_FEATURE_NONSTOP_TSC) && >> !check_tsc_unstable()) >> kvm_clock.rating = 299; >> >> Does your TSC meet the requirements? > > I have set TscInvariant (bit 8) in CPUID_8000_0007_edx and TSC is set as reliable. > > With this I see kvm_clock rating being lowered, but kvm-clock is still being picked as clock-source. Ah.. at later point TSC is picked up, is this expected ? [ 2.564052] clocksource: Switched to clocksource kvm-clock [ 2.678136] clocksource: Switched to clocksource tsc Regards Nikunj
On Thu, Nov 02, 2023 at 05:46:26PM +0530, Nikunj A. Dadhania wrote: > On 11/2/2023 5:37 PM, Nikunj A. Dadhania wrote: > > On 11/2/2023 4:03 PM, Kirill A. Shutemov wrote: > >> On Thu, Nov 02, 2023 at 11:23:34AM +0530, Nikunj A. Dadhania wrote: > >>> On 10/30/2023 10:48 PM, Dave Hansen wrote: > >>>> On 10/29/23 23:36, Nikunj A Dadhania wrote: > >>>> ... > >>>>> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c > >>>>> index 15f97c0abc9d..b0a8546d3703 100644 > >>>>> --- a/arch/x86/kernel/tsc.c > >>>>> +++ b/arch/x86/kernel/tsc.c > >>>>> @@ -1241,7 +1241,7 @@ static void __init check_system_tsc_reliable(void) > >>>>> tsc_clocksource_reliable = 1; > >>>>> } > >>>>> #endif > >>>>> - if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE)) > >>>>> + if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE) || cc_platform_has(CC_ATTR_GUEST_SECURE_TSC)) > >>>>> tsc_clocksource_reliable = 1; > >>>> > >>>> Why can't you just set X86_FEATURE_TSC_RELIABLE? > >>> > >>> Last time when I tried, I had removed my kvmclock changes and I had set > >>> the X86_FEATURE_TSC_RELIABLE similar to Kirill's patch[1], this did not > >>> select the SecureTSC. > >>> > >>> Let me try setting X86_FEATURE_TSC_RELIABLE and retaining my patch for > >>> skipping kvmclock. > >> > >> kvmclock lowers its rating if TSC is good enough: > >> > >> if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC) && > >> boot_cpu_has(X86_FEATURE_NONSTOP_TSC) && > >> !check_tsc_unstable()) > >> kvm_clock.rating = 299; > >> > >> Does your TSC meet the requirements? > > > > I have set TscInvariant (bit 8) in CPUID_8000_0007_edx and TSC is set as reliable. > > > > With this I see kvm_clock rating being lowered, but kvm-clock is still being picked as clock-source. > > Ah.. at later point TSC is picked up, is this expected ? > > [ 2.564052] clocksource: Switched to clocksource kvm-clock > [ 2.678136] clocksource: Switched to clocksource tsc On bare metal I see switch from tsc-early to tsc. tsc-early rating is equal to kvmclock rating after it gets lowered. Maybe kvmclock rating has to be even lower after detecting sane TSC? Sean, Paolo, any comments?
On 11/2/2023 6:08 PM, Kirill A. Shutemov wrote: > On Thu, Nov 02, 2023 at 05:46:26PM +0530, Nikunj A. Dadhania wrote: >> On 11/2/2023 5:37 PM, Nikunj A. Dadhania wrote: >>> On 11/2/2023 4:03 PM, Kirill A. Shutemov wrote: >>>> On Thu, Nov 02, 2023 at 11:23:34AM +0530, Nikunj A. Dadhania wrote: >>>>> On 10/30/2023 10:48 PM, Dave Hansen wrote: >>>>>> On 10/29/23 23:36, Nikunj A Dadhania wrote: >>>>>> ... >>>>>>> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c >>>>>>> index 15f97c0abc9d..b0a8546d3703 100644 >>>>>>> --- a/arch/x86/kernel/tsc.c >>>>>>> +++ b/arch/x86/kernel/tsc.c >>>>>>> @@ -1241,7 +1241,7 @@ static void __init check_system_tsc_reliable(void) >>>>>>> tsc_clocksource_reliable = 1; >>>>>>> } >>>>>>> #endif >>>>>>> - if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE)) >>>>>>> + if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE) || cc_platform_has(CC_ATTR_GUEST_SECURE_TSC)) >>>>>>> tsc_clocksource_reliable = 1; >>>>>> >>>>>> Why can't you just set X86_FEATURE_TSC_RELIABLE? >>>>> >>>>> Last time when I tried, I had removed my kvmclock changes and I had set >>>>> the X86_FEATURE_TSC_RELIABLE similar to Kirill's patch[1], this did not >>>>> select the SecureTSC. >>>>> >>>>> Let me try setting X86_FEATURE_TSC_RELIABLE and retaining my patch for >>>>> skipping kvmclock. >>>> >>>> kvmclock lowers its rating if TSC is good enough: >>>> >>>> if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC) && >>>> boot_cpu_has(X86_FEATURE_NONSTOP_TSC) && >>>> !check_tsc_unstable()) >>>> kvm_clock.rating = 299; >>>> >>>> Does your TSC meet the requirements? >>> >>> I have set TscInvariant (bit 8) in CPUID_8000_0007_edx and TSC is set as reliable. >>> >>> With this I see kvm_clock rating being lowered, but kvm-clock is still being picked as clock-source. >> >> Ah.. at later point TSC is picked up, is this expected ? >> >> [ 2.564052] clocksource: Switched to clocksource kvm-clock >> [ 2.678136] clocksource: Switched to clocksource tsc > > On bare metal I see switch from tsc-early to tsc. tsc-early rating is > equal to kvmclock rating after it gets lowered. For SNP guest with secure tsc enabled, kvm-clock and tsc-early both are at 299. Initially, kvm-clock is selected as clocksource and when tsc with 300 rating is enqueued, clocksource then switches to tsc. [ 0.004231] clocksource: clocksource_enqueue: name kvm-clock rating 299 [...] [ 2.046319] clocksource: clocksource_enqueue: name tsc-early rating 299 [...] [ 3.399179] clocksource: Switched to clocksource kvm-clock [...] [ 3.513652] clocksource: clocksource_enqueue: name tsc rating 300 [ 3.517314] clocksource: Switched to clocksource tsc > Maybe kvmclock rating has to be even lower after detecting sane TSC? If I set kvmclock rating to 298, I do see exact behavior as you have seen on the bare-metal. [ 0.004520] clocksource: clocksource_enqueue: name kvm-clock rating 298 [...] [ 1.827422] clocksource: clocksource_enqueue: name tsc-early rating 299 [...] [ 3.485059] clocksource: Switched to clocksource tsc-early [...] [ 3.623625] clocksource: clocksource_enqueue: name tsc rating 300 [ 3.628954] clocksource: Switched to clocksource tsc Regards Nikunj
On Mon, Nov 06, 2023 at 05:23:44PM +0530, Nikunj A. Dadhania wrote: > > Maybe kvmclock rating has to be even lower after detecting sane TSC? > > If I set kvmclock rating to 298, I do see exact behavior as you have seen on the bare-metal. > > [ 0.004520] clocksource: clocksource_enqueue: name kvm-clock rating 298 > [...] > [ 1.827422] clocksource: clocksource_enqueue: name tsc-early rating 299 > [...] > [ 3.485059] clocksource: Switched to clocksource tsc-early > [...] > [ 3.623625] clocksource: clocksource_enqueue: name tsc rating 300 > [ 3.628954] clocksource: Switched to clocksource tsc This looks more reasonable to me. But I don't really understand timekeeping. It would be nice to hear from someone who knows what he saying.
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index 15f97c0abc9d..b0a8546d3703 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -1241,7 +1241,7 @@ static void __init check_system_tsc_reliable(void) tsc_clocksource_reliable = 1; } #endif - if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE)) + if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE) || cc_platform_has(CC_ATTR_GUEST_SECURE_TSC)) tsc_clocksource_reliable = 1; /*