Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Sat, 14 Oct 2023 10:49:15 +0100
From:   David Woodhouse <dwmw2@infradead.org>
To:     Sean Christopherson <seanjc@google.com>,
        Dongli Zhang <dongli.zhang@oracle.com>
CC:     Joe Jin <joe.jin@oracle.com>, x86@kernel.org, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, pbonzini@redhat.com,
        tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        dave.hansen@linux.intel.com
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_RFC_1/1=5D_KVM=3A_x86=3A_add_par?= =?US-ASCII?Q?am_to_update_master_clock_periodically?=
User-Agent: K-9 Mail for Android
In-Reply-To: <ZSnSNVankCAlHIhI@google.com>
References: <ZRtl94_rIif3GRpu@google.com> <9975969725a64c2ba2b398244dba3437bff5154e.camel@infradead.org> <ZRysGAgk6W1bpXdl@google.com> <d6dc1242ff731cf0f2826760816081674ade9ff9.camel@infradead.org> <ZR2pwdZtO3WLCwjj@google.com> <34057852-f6c0-d6d5-261f-bbb5fa056425@oracle.com> <ZSXqZOgLYkwLRWLO@google.com> <8f3493ca4c0e726d5c3876bb7dd2cfc432d9deaa.camel@infradead.org> <ZSmHcECyt5PdZyIZ@google.com> <cf2b22fc-78f5-dfb9-f0e6-5c4059a970a2@oracle.com> <ZSnSNVankCAlHIhI@google.com>
Message-ID: <BD4C4E71-C743-4B79-93CA-0F3AC5423412@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On 14 October 2023 00:26:45 BST, Sean Christopherson <seanjc@google=2Ecom>=
 wrote:
>> 2=2E Suppose the KVM host has been running for long time, and the drift=
 between
>> two domains would be accumulated to super large? (Even it may not intro=
duce
>> anything bad immediately)
>
>That already happens today, e=2Eg=2E unless the host does vCPU hotplug or=
 is using
>XEN's shared info page, masterclock updates effectively never happen=2E  =
And I'm
>not aware of a single bug report of someone complaining that kvmclock has=
 drifted
>from the host clock=2E  The only bug reports we have are when KVM trigger=
s an update
>and causes time to jump from the guest's perspective=2E

I've got reports about the Xen clock going backwards, and also about it dr=
ifting over time w=2Er=2Et=2E the guest's TSC clocksource so the watchdog i=
n the guest declares its TSC clocksource unstable=2E=20

I don't understand *why* we update the master lock when we populate the Xe=
n shared info=2E Or add a vCPU, for that matter=2E=20

>> The idea is to never update master clock, if tsc is stable (and masterc=
lock is
>> already used)=2E
>
>That's another option, but if there are no masterclock updates, then it s=
uffers
>the exact same (theoretical) problem as #2=2E  And there are real downsid=
es, e=2Eg=2E
>defining when KVM would synchronize kvmclock with the host clock would be
>significantly harder=2E=2E=2E

I thought the definition of such an approach would be that we *never* resy=
nc the kvmclock to anything=2E It's based purely on the TSC value when the =
guest started, and the TSC frequency=2E The pvclock we advertise to all vCP=
Us would be the same, and would *never* change except on migration=2E

(I guess that for consistency we would scale first to the *guest* TSC and =
from that to nanoseconds=2E)

If userspace does anything which makes that become invalid, userspace gets=
 to keep both pieces=2E That includes userspace having to deal with host su=
spend like migration, etc=2E