On Fri, Feb 28, 2025, David Woodhouse wrote: > On Wed, 2025-02-26 at 18:18 -0800, Sean Christopherson wrote: > > This... snowballed a bit. > > > > The bulk of the changes are in kvmclock and TSC, but pretty much every > > hypervisor's guest-side code gets touched at some point. I am reaonsably > > confident in the correctness of the KVM changes. For all other hypervisors, > > assume it's completely broken until proven otherwise. > > > > Note, I deliberately omitted: > > > > Alexey Makhalov <alexey.amakhalov@xxxxxxxxxxxx> > > jailhouse-dev@xxxxxxxxxxxxxxxx > > > > from the To/Cc, as those emails bounced on the last version, and I have zero > > desire to get 38*2 emails telling me an email couldn't be delivered. > > > > The primary goal of this series is (or at least was, when I started) to > > fix flaws with SNP and TDX guests where a PV clock provided by the untrusted > > hypervisor is used instead of the secure/trusted TSC that is controlled by > > trusted firmware. > > > > The secondary goal is to draft off of the SNP and TDX changes to slightly > > modernize running under KVM. Currently, KVM guests will use TSC for > > clocksource, but not sched_clock. And they ignore Intel's CPUID-based TSC > > and CPU frequency enumeration, even when using the TSC instead of kvmclock. > > And if the host provides the core crystal frequency in CPUID.0x15, then KVM > > guests can use that for the APIC timer period instead of manually calibrating > > the frequency. > > > > Lots more background on the SNP/TDX motiviation: > > https://lore.kernel.org/all/20250106124633.1418972-13-nikunj@xxxxxxx > > Looks good; thanks for tackling this. > > I think there are still some things from my older series at > https://lore.kernel.org/all/20240522001817.619072-1-dwmw2@xxxxxxxxxxxxx/ > which this doesn't address. Most definitely. I was/am assuming you're going to send a v4 at some point?
