From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 48C04F9C0 for ; Wed, 8 Jan 2025 14:01:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736344866; cv=none; b=ZFSyQExXQ9feaLNndd5jENHycu4oogUVFH38sU01+pVEpVuDHTvF1bspZ3U3GbWguwXMBPAnQ1Rtwco3bAr8OyFq+Z1stEfHSO2TU4YiSIHOETypxm6y3CFij0WGLLc7JFVkkxqCjheUELanICRo5ZzM0XsVYzHw9VCcPx6g6aU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736344866; c=relaxed/simple; bh=VxYuoDF2a4u1sXO5+YYQjOrZAtLkpujcDAhNHFETGp0=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=J4SAFD8K/4YX5cniGTA6qrXUyUCxX/4pZEvZvUKitxIIXnWDlx3+eFt7c4XA8IJZW+DerlefKsYKDsn0zhMiC0GMmGkbQ0U84LWnHH6P+LtSwyMYwMWqjA24dqVL750XaFIolakgkRmGCiuA+JkLtrCgx0c7YqiTP+JfqlKzW+M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=FHKeTEwh; arc=none smtp.client-ip=209.85.214.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="FHKeTEwh" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-21631cbf87dso225672175ad.3 for ; Wed, 08 Jan 2025 06:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736344861; x=1736949661; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=KoSb0DVqwwdqCnPFQHqX9QxKv5379dwSqLcL746sAZA=; b=FHKeTEwhdPHGBTwEhvYROgjoeSS8wCsLDm+yF/8TNUOiwU8DY6d+4bp2vWoTRW4bOa myYoatXAcqzGHJNiG9/yKzF60JGKJW06J6obMIIz0KHNfOZhG1/u4reg2v6+FXQ/g58n jp0TMLKvAUeezouHL6WRola2gzRrsxSDynYhGDOcnGEZrluRoIq3x3CGvzsRyOX5Yv9i y6xjISoxSPWnosj7zA+IfqE9Sqd3/PSNsElb6Ja/0Nb57YdDRfSTaVHYkwOLQLa2utKr fsIJJmwMweczi1bBEInMZDHHjM9J1ZvzW7ePP5bNnVG2IejZY84t7KCy6I36+RAxk4GQ uw8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736344861; x=1736949661; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KoSb0DVqwwdqCnPFQHqX9QxKv5379dwSqLcL746sAZA=; b=I1pWhYSEVlM9dtNVzy1tQo/on/V4/uIXX0izKhFzqxmPmlF9bwnGbXOK1jrBKQ5XRc gH8zIBWrKCJ2mn7+Z32IxHUX/D2ivbbPHgxSdRgJhhvJ8TGFgzir5XyMsDbOAhXB1mto 0gVIMWaXfeLyNdkyktjmG+vRtotU/0zZkX+SXXdiktF1D8xGTRtvgVDdK4op79skqkVg h+QPCpHaL57PZijnTzJZ+onOlNmQxQBf4+09c+zqEdg7K2juDE78jBowRrls1lq6J6LR HcXqbeynhGwwWRu3AUEk6gHKd0muHrJCPU5Yv4caMCM200TzW13RcIs0fbweUJF1YCwY +YgQ== X-Forwarded-Encrypted: i=1; AJvYcCWCYVvXdDJo4qIy2AfQId3/GFLFXRJDR6J9qKFsV5OTsR7n8FbnLEz5Y8NniIr0ySMWg1Nkjald0TDK1pw=@vger.kernel.org X-Gm-Message-State: AOJu0YxB2FjhRtAKxdVgQj4dS8ojZBwwYyk18e8lP4rj+m4A3CjuBYYB haMEO8MRMMSEKdsnnS5P2K6ECPO4Lb2YeISBuPeXW1MBa2C/BgcLYRB6kG1xQBb5HHu6zjnvFCh F/w== X-Google-Smtp-Source: AGHT+IHG7dyfKAL1bSiG38RaEeMjMKlAgfX1dqFkBaWY/kQlYp650airghqKnbSSTqx7qJ4Xpssouik/k1E= X-Received: from pgjs17.prod.google.com ([2002:a63:f051:0:b0:7fd:561e:62dd]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:748b:b0:1e1:a0b6:9861 with SMTP id adf61e73a8af0-1e88d0e21dbmr5275883637.12.1736344861510; Wed, 08 Jan 2025 06:01:01 -0800 (PST) Date: Wed, 8 Jan 2025 06:00:59 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250106124633.1418972-1-nikunj@amd.com> <20250106124633.1418972-13-nikunj@amd.com> <20250107193752.GHZ32CkNhBJkx45Ug4@fat_crate.local> <3acfbef7-8786-4033-ab99-a97e971f5bd9@amd.com> <20250108082221.GBZ341vUyxrBPHgTg3@fat_crate.local> <4b68ee6e-a6b2-4d41-b58f-edcceae3c689@amd.com> Message-ID: Subject: Re: [PATCH v16 12/13] x86/tsc: Switch to native sched clock From: Sean Christopherson To: "Nikunj A. Dadhania" Cc: Borislav Petkov , linux-kernel@vger.kernel.org, thomas.lendacky@amd.com, x86@kernel.org, kvm@vger.kernel.org, mingo@redhat.com, tglx@linutronix.de, dave.hansen@linux.intel.com, pgonda@google.com, pbonzini@redhat.com, francescolavra.fl@gmail.com, Alexey Makhalov , Juergen Gross , Boris Ostrovsky Content-Type: text/plain; charset="us-ascii" On Wed, Jan 08, 2025, Nikunj A. Dadhania wrote: > > On 1/8/2025 2:04 PM, Nikunj A. Dadhania wrote: > > > >> If you want to take care only of STSC now, I'd take a patch which is known > >> good and tested properly. And that should happen very soon because the merge > >> window is closing in. > > > > In that case, let me limit this only to STSC for now, i will send updated patch. > > From: Nikunj A Dadhania > Date: Wed, 8 Jan 2025 14:18:04 +0530 > Subject: [PATCH] x86/kvmclock: Prefer TSC as the scheduler clock for Secure > TSC guests > > Although the kernel switches over to a stable TSC clocksource instead of > kvmclock, the scheduler still keeps on using kvmclock as the sched clock. > This is due to kvm_sched_clock_init() updating the pv_sched_clock() > unconditionally. Do not override the PV sched clock when Secure TSC is > enabled. > > Signed-off-by: Nikunj A Dadhania > --- > arch/x86/kernel/kvmclock.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c > index d8fef3a65a35..82c4743a5e7a 100644 > --- a/arch/x86/kernel/kvmclock.c > +++ b/arch/x86/kernel/kvmclock.c > @@ -324,8 +324,10 @@ void __init kvmclock_init(void) > if (kvm_para_has_feature(KVM_FEATURE_CLOCKSOURCE_STABLE_BIT)) > pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT); > > - flags = pvclock_read_flags(&hv_clock_boot[0].pvti); > - kvm_sched_clock_init(flags & PVCLOCK_TSC_STABLE_BIT); > + if (!cc_platform_has(CC_ATTR_GUEST_SNP_SECURE_TSC)) { > + flags = pvclock_read_flags(&hv_clock_boot[0].pvti); > + kvm_sched_clock_init(flags & PVCLOCK_TSC_STABLE_BIT); > + } This still misses my point. Ditto for the "x86/tsc: Switch Secure TSC guests away from kvm-clock". I object to singling out kvmclock. It's weird and misleading, because handling only kvmclock suggests that other PV clocks are somehow trusted/ok, when in reality the only reason kvmclock is getting singled out is (presumably) because it's what Nikunj and the other folks enabling KVM SNP test on. What I care most about is having a sane, consistent policy throughout the kernel. E.g. so that a user/reader walks away with an understanding PV clocks are a theoretical host attack vector and so should be avoided when Secure TSC is available. Ideally, if the TSC is the preferred clocksource, then the scheduler will use the TSC and not a PV clock irrespective of STSC. But I 100% agree with Boris that it needs buy-in from other maintainers (including Paolo), because it's entirely possible (likely, even) that there's an angle to scheduling I'm not considering.