From: Sean Christopherson <seanjc@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v8 05/17] KVM: x86: Avoid NTP frequency skew for KVM clock on 32-bit host
Date: Fri, 7 Aug 2026 09:01:38 -0700 [thread overview]
Message-ID: <anYBYu4rx-jCv8gr@google.com> (raw)
In-Reply-To: <anUmdhx0Dh-yd89z@google.com>
+David (I realized I'm having a conversation between me, myself, and Sashiko)
On Thu, Aug 06, 2026, Sean Christopherson wrote:
> On Wed, Aug 05, 2026, Sean Christopherson wrote:
> > On Wed, Aug 05, 2026, sashiko-bot@kernel.org wrote:
> > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > > index 3107878a6fe5d..8f469fd9863f9 100644
> > > > --- a/arch/x86/kvm/x86.c
> > > > +++ b/arch/x86/kvm/x86.c
> > >
> > > [ ... ]
> > >
> > > > @@ -915,13 +914,6 @@ static s64 get_kvmclock_base_ns(void)
> > > > /* Count up from boot time, but with the frequency of the raw clock. */
> > > > return ktime_to_ns(ktime_add(ktime_get_raw(), pvclock_gtod_data.offs_boot));
> > >
> > > [Severity: Low]
> > > Will reading the 64-bit pvclock_gtod_data.offs_boot without seqcount
> > > protection or data_race() annotations trigger KCSAN data race warnings on
> > > 32-bit systems?
> > >
> > > By removing the ktime_get_boottime_ns() fallback, this read now executes on
> > > 32-bit architectures where it compiles to two non-atomic 32-bit accesses.
> > > If a KVM vCPU thread calls get_kvmclock_base_ns() while a timer interrupt
> > > runs timekeeping_update(), it overwrites offs_boot.
> > >
> > > Even though the value only actually changes during suspend when the freezer
> > > subsystem guarantees vCPU threads are frozen (preventing functional tearing),
> > > overwriting the identical value concurrently with an unprotected read still
> > > introduces a formal C11 data race.
> >
> > Huh. And strictly speaking, 64-bit could tear the store/load. Stealing heavily
> > from ktime_mono_to_any(), this as a prep patch plus fixup (not yet tested)?
>
> LOL, hilarious. I was cherry-picking the rest of the series on top to run the
> tests, and discovered that "Compute kvmclock base without pvclock_gtod_data"
> does exactly that: uses ktime_mono_to_any() directly. So at least I went in the
> right direction?
>
> David, is there any reason that patch needs to be 25/36? AFAICT, it slots in
> very nicely before this patch. Then we don't need to do the below, because
> ktime_mono_to_any() already takes care of 32-bit.
Same question for "KVM: x86: Use ktime_get_snapshot_id() for master clock". I
don't see any obvious dependencies in here:
KVM: x86: Re-synchronize TSC after KVM_SET_TSC_KHZ
KVM: x86: Remove runtime Xen TSC frequency CPUID update
KVM: x86: Avoid redundant masterclock updates from multiple vCPUs
KVM: x86/xen: Prevent runstate times from becoming negative
KVM: x86: Avoid gratuitous global clock updates
KVM: x86: Factor out kvm_use_master_clock()
KVM: x86: Allow KVM master clock mode when TSCs are offset from each other
KVM: x86: Replace nr_vcpus_matched_tsc count with all_vcpus_matched_tsc bool
KVM: x86: Kill last_tsc_{nsec,write,offset} fields
KVM: x86: Improve synchronization in kvm_synchronize_tsc()
And if I pull those in earlier, and grab these two (which AFICT also don't have
dependencies either):
KVM: x86: Remove runtime Xen TSC frequency CPUID update
KVM: x86/xen: Prevent runstate times from becoming negative
Then what's left fits nicely into two or three buckets:
1: Masterclock overhaul
2. New uAPI and tests
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index b6e1dfd6db6a..57679d871581 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -921,7 +921,8 @@ static void update_pvclock_gtod(struct timekeeper *tk)
> >
> > vdata->wall_time_sec = tk->xtime_sec;
> >
> > - vdata->offs_boot = tk->offs_boot;
> > + /* Pairs with the READ_ONCE() in get_kvmclock_base_ns(). */
> > + WRITE_ONCE(vdata->offs_boot, tk->offs_boot);
> >
> > write_seqcount_end(&vdata->seq);
> > }
> > @@ -929,7 +930,26 @@ static void update_pvclock_gtod(struct timekeeper *tk)
> > static s64 get_kvmclock_base_ns(void)
> > {
> > /* Count up from boot time, but with the frequency of the raw clock. */
> > - return ktime_to_ns(ktime_add(ktime_get_raw(), pvclock_gtod_data.offs_boot));
> > + struct pvclock_gtod_data *gtod = &pvclock_gtod_data;
> > + ktime_t raw = ktime_get_raw();
> > + ktime_t now;
> > +
> > + /*
> > + * Synchronization with clock updates isn't required on 64-bit as only
> > + * one field is being consume
> > + * */
> > +#ifdef CONFIG_X86_64
> > + now = ktime_add(raw, READ_ONCE(gtod->offs_boot));
> > +#else
> > + unsigned int seq;
> > +
> > + do {
> > + seq = read_seqcount_begin(>od->seq);
> > + now = ktime_add(raw, *offset);
> > + } while (read_seqcount_retry(gtod->seq, seq));
> > +#endif
> > +
> > + return ktime_to_ns(now);
> > }
> >
> > static uint32_t div_frac(uint32_t dividend, uint32_t divisor)
next prev parent reply other threads:[~2026-08-07 16:01 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 23:39 [PATCH v8 00/17] KVM: x86: Cleaning up the KVM clock mess, part 1 Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 01/17] KVM: x86: Update "last guest TSC" snapshot prior to enabling IRQs/preemption Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 02/17] KVM: x86: Improve accuracy of KVM clock when TSC scaling is in force Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 03/17] KVM: x86: Explicitly disable TSC scaling without CONSTANT_TSC Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 04/17] KVM: x86: Activate master clock immediately on vCPU creation Sean Christopherson
2026-08-05 0:06 ` sashiko-bot
2026-08-05 9:11 ` David Woodhouse
2026-08-05 15:02 ` Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 05/17] KVM: x86: Avoid NTP frequency skew for KVM clock on 32-bit host Sean Christopherson
2026-08-05 0:02 ` sashiko-bot
2026-08-05 18:21 ` Sean Christopherson
2026-08-07 0:27 ` Sean Christopherson
2026-08-07 16:01 ` Sean Christopherson [this message]
2026-08-07 17:26 ` David Woodhouse
2026-08-08 15:08 ` David Woodhouse
2026-08-04 23:39 ` [PATCH v8 06/17] KVM: x86: Drop unnecessary CPU pinning when computing/getting kvmclock Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 07/17] KVM: x86: Move "no master clock" fallback from __get_kvmclock() to get_kvmclock() Sean Christopherson
2026-08-04 23:52 ` sashiko-bot
2026-08-05 15:17 ` Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 08/17] KVM: x86: Wrap all of __get_kvmclock_master_clock() with CONFIG_X86_64=y Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 09/17] KVM: x86: Fall back to non-master-clock if clockread fails in get_kvmclock() Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 10/17] KVM: x86: Fix KVM clock precision in get_kvmclock() with TSC scaling Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 11/17] KVM: x86: Use get_kvmclock() in kvm_get_wall_clock_epoch() Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 12/17] KVM: x86: Fix compute_guest_tsc() to handle negative time deltas Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 13/17] KVM: x86: Disable preemption, not IRQs, when getting TSC+freq pair Sean Christopherson
2026-08-04 23:56 ` sashiko-bot
2026-08-05 15:16 ` Sean Christopherson
2026-08-05 15:55 ` David Woodhouse
2026-08-05 16:22 ` Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 14/17] KVM: x86: Make master clock logic in guest PV clock updates 64-bit only Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 15/17] KVM: x86: Upscale TSC to "now", not master clock when updating PV clocks Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 16/17] KVM: x86: Simplify and comment kvm_get_time_scale() Sean Christopherson
2026-08-04 23:39 ` [PATCH v8 17/17] KVM: x86: Remove implicit rdtsc() from kvm_compute_l1_tsc_offset() Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anYBYu4rx-jCv8gr@google.com \
--to=seanjc@google.com \
--cc=dwmw2@infradead.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox