linux-kernel - Re: pvclock time drifting backward

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <eaa33f756bc2e66ca193180a9847ee43fbdaa8ad.camel@infradead.org>
Date: Sat, 29 Mar 2025 08:20:32 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Ming Lin <minggr@...il.com>
Cc: Sean Christopherson <seanjc@...gle.com>, kvm@...r.kernel.org, Paolo
 Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: pvclock time drifting backward

On Fri, 2025-03-28 at 11:30 -0700, Ming Lin wrote:
> 
> > 
> > Is this live migration from one VMM to another on the same host, so we
> > don't have to worry about the accuracy of the TSC itself? The guest TSC
> > remains consistent? And presumably your host does *have* a stable TSC,
> > and the guest's test case really ought to be checking the
> > PVCLOCK_TSC_STABLE_BIT to make sure of that?
> 
> The live migration is from one VMM to another on a remote host, and we
> have also observed the same issue during live upgrades on the same host.

Moving to a remote host also requires that you get the guest TSC to be
reasonably synchronised on the destination. Which is another litany of
sadness, especially if you have TSC scaling in the mix. Or even if your
two "identical" hosts calculated a slightly different TSC frequency
when they measured it at first boot.

In that latter case, the mul/scale factors advertised to the guest in
the pvclock will be *slightly* different on the new host. Your test in
the guest would then fail if it requires that the pvclock be
*identical*. The actual criterion is that the result should be
identical at the time of the live migration (when the TSC frequency
effectively changes).

The code currently requires that the old and new TSC frequencies are
within ±1kHz of each other.

> > 
> > If all the above assumptions/interpretations of mine are true, I still
> > think it's expected that your clock will jump on live migration
> > *unless* you also taught your VMM to use the new KVM_[GS]ET_CLOCK_GUEST
> > ioctls which were added in my patch series, specifically to preserve
> > the mathematical relationship between guest TSC and kvmclock across a
> > migration.
> > 
> 
> We are planning to test the patches on a 6.9 kernel (where they can be
> applied cleanly) and modify the live upgrade/migration code to use the new
> KVM_[GS]ET_CLOCK_GUEST ioctls.
> 
> BTW, what is the plan for upstreaming these patches?

I need to find the time to rebase, rework and retest them. You're doing
some of the testing and increasing the motivation... I'll see if I can
get it done in the next week or three.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)