[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250102104519.GFZ3ZuPx8z57jowOWr@fat_crate.local>
Date: Thu, 2 Jan 2025 11:45:19 +0100
From: Borislav Petkov <bp@...en8.de>
To: "Nikunj A. Dadhania" <nikunj@....com>
Cc: thomas.lendacky@....com, linux-kernel@...r.kernel.org, x86@...nel.org,
kvm@...r.kernel.org, mingo@...hat.com, tglx@...utronix.de,
dave.hansen@...ux.intel.com, pgonda@...gle.com, seanjc@...gle.com,
pbonzini@...hat.com
Subject: Re: [PATCH v15 09/13] tsc: Use the GUEST_TSC_FREQ MSR for
discovering TSC frequency
On Thu, Jan 02, 2025 at 03:31:49PM +0530, Nikunj A. Dadhania wrote:
> Sure, how about the below:
>
> For SecureTSC enabled guests, TSC frequency should be obtained from the platform
> provided GUEST_TSC_FREQ MSR (C001_0134h). As paravirt clock(kvm-clock) has over-ridden
> x86_platform.calibrate_cpu() and x86_platform.calibrate_tsc() callbacks,
> SecureTSC needs to override them with its own callbacks.
Not really.
It's like you're in a contest of "how to write a commit message which is the
shortest and has as less information as possible."
Go back, read the subthread and summarize, please, what has been discussed
here and for patch 12.
I'm missing the big picture about the relationship between kvmclock and TSC
in STSC guests.
After asking so many questions, it sounds to me like this patch and patch 12
should be merged into one and there it should be explained what the strategy
is when a STSC guest loads and how kvmclock is supposed to be handled, what is
allowed, what is warned about, when the guest terminates what is tainted,
yadda yadda.
This all belongs in a single patch logically.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists