[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ab9dc76-4556-4a96-be0d-2c8ee942b113@amd.com>
Date: Thu, 9 Jan 2025 12:02:14 +0530
From: "Nikunj A. Dadhania" <nikunj@....com>
To: Sean Christopherson <seanjc@...gle.com>, Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, thomas.lendacky@....com, x86@...nel.org,
kvm@...r.kernel.org, mingo@...hat.com, tglx@...utronix.de,
dave.hansen@...ux.intel.com, pgonda@...gle.com, pbonzini@...hat.com,
francescolavra.fl@...il.com, Alexey Makhalov <alexey.makhalov@...adcom.com>,
Juergen Gross <jgross@...e.com>, Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [PATCH v16 12/13] x86/tsc: Switch to native sched clock
On 1/8/2025 10:32 PM, Sean Christopherson wrote:
> On Wed, Jan 08, 2025, Borislav Petkov wrote:
>> On Wed, Jan 08, 2025 at 06:00:59AM -0800, Sean Christopherson wrote:
> For TDX guests, the TSC is _always_ "secure". So similar to singling out kvmclock,
> handling SNP's STSC but not the TDX case again leaves the kernel in an inconsistent
> state. Which is why I originally suggested[*] fixing the sched_clock mess in a
> generically;
> doing so would avoid the need to special case SNP or TDX in code> that doesn't/shouldn't care about SNP or TDX.
That is what I have attempted in this patch[1] where irrespective of SNP/TDX, whenever
TSC is picked up as a clock source, sched-clock will start using TSC instead of any
PV sched clock. This does not have any special case for STSC/SNP/TDX.
> [*] https://lore.kernel.org/all/ZurCbP7MesWXQbqZ@google.com
Regards
Nikunj
1. https://lore.kernel.org/kvm/20250106124633.1418972-13-nikunj@amd.com/
Powered by blists - more mailing lists