On Thu, Jan 02, 2025 at 06:40:38PM +0530, Nikunj A. Dadhania wrote:
> ---------------------------------------------------------------------------
> x86/tsc: Use the GUEST_TSC_FREQ MSR for discovering TSC frequency
>
> Although the kernel switches over to stable TSC clocksource instead of
> kvm-clock, TSC frequency calibration still keeps on using the kvm-clock
> based frequency calibration. This is due to kvmclock_init() updating the
> x86_platform's CPU and TSC callbacks unconditionally.
>
> For SecureTSC enabled guests, use the GUEST_TSC_FREQ MSR to discover the
> TSC frequency instead of relying on kvm-clock based frequency calibration.
> Override both CPU and TSC frequency calibration callbacks with
> securetsc_get_tsc_khz(). As difference between CPU base and TSC frequency
> does not apply in this case same callback is being used.
> ---------------------------------------------------------------------------
Ok.
> ---------------------------------------------------------------------------
> x86/kvmclock: Warn when kvmclock is selected for SecureTSC enabled guests
>
> Warn users when kvmclock is selected as the clock source for SecureTSC enabled
> guests. Users can change the clock source to kvm-clock using the sysfs interface
> while running on a Secure TSC enabled guest. Switching to the hypervisor-controlled
> kvmclock defeats the purpose of using SecureTSC.
>
> Taint the kernel and issue a warning to the user when the clock source switches
> to kvmclock, ensuring they are aware of the change and its implications.
>
> ---------------------------------------------------------------------------
Ok.
> ○ Modern CPU/VMs: VMs running on platforms supporting constant, non-stop and reliable TSC
Modern?
What guarantees do you have on "modern" setups that the HV has no control over
the TSC MSRs? None.
The only guarantee you have is when the TSC MSRs are not intercepted - IOW,
you're a STSC guest.
So none of that modern stuff means anything - your only case is a STSC guest
where you can somewhat reliably know in the guest that the host is not lying
to you.
So the only configuration is a STSC guest - everything else should use
kvm-clock.
AFAIU.
> > 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.
Now, why aren't you merging patch 9 and 12 into one and calling it:
"Switch Secure TSC guests away from kvm-clock"
or so, where you switch a STSC guest to use the TSC MSRs and
warn/taint/terminate the guest if the user chooses otherwise?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
