From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 742F7442FD7 for ; Mon, 10 Aug 2026 20:56:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.198 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786395390; cv=none; b=fRZIoEJWevn1w3ds7xSb1iwN7AEsTWFK/POBrAzyeWNgorKJqWiz2l7qC4zf5UUSYXGZ7DjXDyvdf+vFNwtu2/8hJp7n2H0A0sdzcHDpcyuuP8D3XLPBONThHeemPl5sD6Jvmxsh/LPOc8V4M8NF2eMtaTtgyhoPM2RVRyTdPPw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786395390; c=relaxed/simple; bh=gV3PXNtOPo2dzqJVberp/Nshsac9CmoYYB8G1uWRGMw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=MT9UG36bGlRyAyvTnmLxnij9yOxC1JEyvlp4mp0MMaog+EGGDBiCxFSv5CfNct/R4el7yaq63x8Up1+t0Udg+fW56LE7Xq1xrxcIP4Grv0+/uPBWC+UGWxZQQtuQvpW03+UgUl9mFMpG/wPiF6ikbpmdr/inixT7heGLbnRp8ZE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=bNFSUFW+; arc=none smtp.client-ip=209.85.215.198 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="bNFSUFW+" Received: by mail-pg1-f198.google.com with SMTP id 41be03b00d2f7-cbb6433e9d4so3786752a12.3 for ; Mon, 10 Aug 2026 13:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786395387; x=1787000187; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=LCgbuv6Vd7zF2bZTNz0VWHu3WJNY8tSX432zegD8YdU=; b=bNFSUFW+Hwr1m2QoQQwTY3YLdMhY07wlQ2bWpfNlmdFRpWQnc/9ugInC3tOqzfMCju qRkuPEQU1eqU85C4yzJPYQPaGAS1NrW6s8oMOQkjf9LCNSed118JxqCZt92MV5fp4qVy ObWZnmkn+jj4R8IK8TJS1IHNyfzswodPXaxpdIzSe4cdl/ysXHSfo3z7DXfez+w/P4kW dWP4m2QDSle7h3cdAfJ+vkgb9jL2irTF3Zm69u9qOjGuzdMqF9wU4pTW+s2oYvycioJ6 Gf1Ms5ppjgdu0N8nRrLJUTdn5RY3cc1yDhLdWVKydyYGg9Vgjfs5D6EY2FjrQANEoOMF I5ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786395387; x=1787000187; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=LCgbuv6Vd7zF2bZTNz0VWHu3WJNY8tSX432zegD8YdU=; b=jBwiXWVIKuU9deDUx1Wi0Hwp8NrVV+7h5j5eDRhDmUooCQZrzrTpXEVUBvPWkLvcY+ PlxphmEaHzJKVGVBAfWE5jUfUKxfefLbMvUImPYRQqslgYzxXmIUSmSPQX9gOVBs6lQO 3HaEoAD/EPQkBpB9lqoStMm0BM1aK/Phbr+TANsYEYpijo5u0AESJLOvhHtBNXs58QOp Gl9duas2Lkg8qpCRg1eKFSQ0TbsjZdBRmHM1qgE4oKNPUICjWk12BMSR8wGjV/BQ5wAz CaMUsT45ZgIdvxqiLyKFl8bmifvmsHBcy+hrWZDInnyubTbc2DxzMUfjs73yCi5bZ5f0 bioA== X-Forwarded-Encrypted: i=1; AHgh+RrPjAjW/Wsrb+Ug3rhdTmVgUBcDw2jK4p1Ou+1qqggwAs6hXVRA2pTSnpXabuqVAv9M42MVqP5Zj5NHRGI=@vger.kernel.org X-Gm-Message-State: AOJu0Yz658J2Me5qS7XzkGCquylPQN/9/l38SSxqWSXRNZQYGoFYgGGE rmhv6j+RKebu4l5ez5jLdvYeceAgol0lh1maYXgrqREPiGYDIL57OurC0qbu39ydCV+SHZiWMB9 E5y59cw== X-Received: from pgmc19.prod.google.com ([2002:a63:1c53:0:b0:c98:2639:852e]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:ad1:b0:848:4d1a:9556 with SMTP id d2e1a72fcca58-84f9c8f6a11mr4384666b3a.11.1786395387317; Mon, 10 Aug 2026 13:56:27 -0700 (PDT) Date: Mon, 10 Aug 2026 13:56:26 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260728144954.355376-1-dwmw2@infradead.org> <20260728144954.355376-18-dwmw2@infradead.org> Message-ID: Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs are offset from each other From: Sean Christopherson To: David Woodhouse Cc: Paolo Bonzini , Jonathan Corbet , Shuah Khan , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Vitaly Kuznetsov , Juergen Gross , Boris Ostrovsky , Paul Durrant , Jonathan Cameron , Sascha Bischoff , Marc Zyngier , Joey Gouly , Jack Allister , Dongli Zhang , joe.jin@oracle.com, kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 10, 2026, David Woodhouse wrote: > On Mon, 2026-08-10 at 10:47 -0700, Sean Christopherson wrote: > > =C2=A0 > > > 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. > >=20 > > It's not though?=C2=A0 The value stored in kvmclock->tsc_timestamp is p= er-VM, not > > per-vCPU, when using the master clock.=C2=A0 It's a little easier to se= e once the > > master clock TSC isn't shoved into host_tsc: > >=20 > > do { > > seq =3D read_seqcount_begin(&ka->pvclock_sc); > > use_master_clock =3D ka->use_master_clock; > > if (!use_master_clock) > > continue; > >=20 > > if (!kvm_get_time_and_clockread(&kernel_ns, &host_tsc)) { > > use_master_clock =3D false; > > continue; > > } > >=20 > > master_tsc =3D ka->master_cycle_now; > > master_ns =3D ka->master_kernel_ns; > > } while (read_seqcount_retry(&ka->pvclock_sc, seq)); > >=20 > > ... > >=20 > > if (use_master_clock) { > > hv_clock.tsc_timestamp =3D kvm_read_l1_tsc(v, master_tsc); > > hv_clock.system_time =3D master_ns + v->kvm->arch.kvmclock_offset; > > } else { > > hv_clock.tsc_timestamp =3D tsc_timestamp; > > hv_clock.system_time =3D kernel_ns + v->kvm->arch.kvmclock_offset; > > } >=20 > Meh. I shall have to build a better test case for that one. Thanks. >=20 > > To allow different offsets, KVM would need to track a per-vCPU offset t= o 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 pos= sible I'm > > missing something obvious). >=20 > 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. But why though? What is the harm to the host or guest? E.g. does it make = it more difficult to accurately migrate the VM? I'm not opposed to allowing master= -clock mode with diverging offsets, just trying to understand why it matters.