On Mon, 2026-08-10 at 10:47 -0700, Sean Christopherson wrote:
>
> > But when the vCPUs merely have a different TSC *offset*, that's not a
> > problem. The offset is applied to that vCPU's kvmclock->tsc_timestamp
> > field, and it all comes out in the wash.
>
> It's not though? The value stored in kvmclock->tsc_timestamp is per-VM, not
> per-vCPU, when using the master clock. It's a little easier to see once the
> master clock TSC isn't shoved into host_tsc:
>
> do {
> seq = read_seqcount_begin(&ka->pvclock_sc);
> use_master_clock = ka->use_master_clock;
> if (!use_master_clock)
> continue;
>
> if (!kvm_get_time_and_clockread(&kernel_ns, &host_tsc)) {
> use_master_clock = false;
> continue;
> }
>
> master_tsc = ka->master_cycle_now;
> master_ns = ka->master_kernel_ns;
> } while (read_seqcount_retry(&ka->pvclock_sc, seq));
>
> ...
>
> if (use_master_clock) {
> hv_clock.tsc_timestamp = kvm_read_l1_tsc(v, master_tsc);
> hv_clock.system_time = master_ns + v->kvm->arch.kvmclock_offset;
> } else {
> hv_clock.tsc_timestamp = tsc_timestamp;
> hv_clock.system_time = kernel_ns + v->kvm->arch.kvmclock_offset;
> }Meh. I shall have to build a better test case for that one. Thanks. > To allow different offsets, KVM would need to track a per-vCPU offset to the > master clock and apply that in kvm_guest_time_update() (and maybe other > places?). > Which is doable, but it's not clear to me why we'd want to support that > (though > I haven't fully processed the back half ot his series, so it's very possible > I'm > missing something obvious). Because I want to reduce the number of cases where we have to fall back to non-masterclock mode. Especially the ones which are driven by *guests* rather than weird choices on the VMM's part.
smime.p7s
Description: S/MIME cryptographic signature
