[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <99ad4b92-7598-4ee3-92da-60efb87d08f1@xen.org>
Date: Tue, 4 Feb 2025 09:26:01 +0000
From: Paul Durrant <xadimgnik@...il.com>
To: Sean Christopherson <seanjc@...gle.com>,
Paolo Bonzini <pbonzini@...hat.com>, David Woodhouse <dwmw2@...radead.org>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
syzbot+352e553a86e0d75f5120@...kaller.appspotmail.com,
Paul Durrant <pdurrant@...zon.com>, David Woodhouse <dwmw@...zon.co.uk>,
Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [PATCH v2 05/11] KVM: x86/xen: Use guest's copy of pvclock when
starting timer
On 01/02/2025 01:38, Sean Christopherson wrote:
> Use the guest's copy of its pvclock when starting a Xen timer, as KVM's
> reference copy may not be up-to-date, i.e. may yield a false positive of
> sorts. In the unlikely scenario that the guest is starting a Xen timer
> and has used a Xen pvclock in the past, but has since but turned it "off",
> then vcpu->arch.hv_clock may be stale, as KVM's reference copy is updated
> if and only if at least one pvclock is enabled.
>
> Furthermore, vcpu->arch.hv_clock is currently used by three different
> pvclocks: kvmclock, Xen, and Xen compat. While it's extremely unlikely a
> guest would ever enable multiple pvclocks, effectively sharing KVM's
> reference clock could yield very weird behavior. Using the guest's active
> Xen pvclock instead of KVM's reference will allow dropping KVM's
> reference copy.
>
> Fixes: 451a707813ae ("KVM: x86/xen: improve accuracy of Xen timers")
> Cc: Paul Durrant <pdurrant@...zon.com>
> Cc: David Woodhouse <dwmw@...zon.co.uk>
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> ---
> arch/x86/kvm/xen.c | 65 ++++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 60 insertions(+), 5 deletions(-)
>
Reviewed-by: Paul Durrant <paul@....org>
Powered by blists - more mailing lists