Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Date:   Tue, 31 Oct 2023 12:11:39 +0000
From:   David Woodhouse <dwmw2@infradead.org>
To:     paul@xen.org, Paul Durrant <xadimgnik@gmail.com>,
        kvm@vger.kernel.org, linux-kernel@vger.kernel.org
CC:     Sean Christopherson <seanjc@google.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] KVM: x86/xen: improve accuracy of Xen timers
User-Agent: K-9 Mail for Android
In-Reply-To: <6c9671b4-d997-42ac-9821-06accb97357f@xen.org>
References: <96da7273adfff2a346de9a4a27ce064f6fe0d0a1.camel@infradead.org> <1a679274-bbff-4549-a1ea-c7ea9f1707cc@xen.org> <F80266DD-D7EF-4A26-B9F8-BC33EC65F444@infradead.org> <6c9671b4-d997-42ac-9821-06accb97357f@xen.org>
Message-ID: <1DCDC3DB-81E8-426C-AF4B-AA7CA2C1271E@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On 31 October 2023 12:06:17 GMT, Paul Durrant <xadimgnik@gmail=2Ecom> wrot=
e:
>On 31/10/2023 11:42, David Woodhouse wrote:
>> Secondly, it's also wrong thing to do in the general case=2E Let's say =
KVM does its thing and snaps the kvmclock backwards in time on a KVM_REQ_CL=
OCK_UPDATE=2E=2E=2E do we really want to reinterpret existing timers agains=
t the new kvmclock? They were best left alone, I think=2E
>
>Do we not want to do exactly that? If the master clock is changed, why wo=
uld we not want to re-interpret the guest's idea of time? That update will =
be visible to the guest when it re-reads the PV clock source=2E

Well no, because the guest set that timer *before* we yanked the clock fro=
m under it, and probably wants it interpreted in the time scale which was i=
n force at the time it was set=2E

But more to the point, KVM shouldn't be doing that! We need to *fix* the k=
vmclock brokenness, not design further band-aids around it=2E

As I said, this patch stands even *after* we fix kvmclock, because it hand=
les the timer delta calculation from an single TSC read=2E

But overengineering a timer reset on KVM_REQ_CLOCK_UPDATE would not=2E