[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8038e5c0-d0dc-4582-b076-3d514656af1e@xen.org>
Date: Tue, 4 Feb 2025 09:31:16 +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 07/11] KVM: x86: Set PVCLOCK_GUEST_STOPPED only for
kvmclock, not for Xen PV clock
On 01/02/2025 01:38, Sean Christopherson wrote:
> Handle "guest stopped" propagation only for kvmclock, as the flag is set
> if and only if kvmclock is "active", i.e. can only be set for Xen PV clock
> if kvmclock *and* Xen PV clock are in-use by the guest, which creates very
> bizarre behavior for the guest.
>
> Simply restrict the flag to kvmclock, e.g. instead of trying to handle
> Xen PV clock, as propagation of PVCLOCK_GUEST_STOPPED was unintentionally
> added during a refactoring, and while Xen proper defines
> XEN_PVCLOCK_GUEST_STOPPED, there's no evidence that Xen guests actually
> support the flag.
>
> Check and clear pvclock_set_guest_stopped_request if and only if kvmclock
> is active to preserve the original behavior, i.e. keep the flag pending
> if kvmclock happens to be disabled when KVM processes the initial request.
>
> Fixes: aa096aa0a05f ("KVM: x86/xen: setup pvclock updates")
> Cc: Paul Durrant <pdurrant@...zon.com>
> Cc: David Woodhouse <dwmw@...zon.co.uk>
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> ---
> arch/x86/kvm/x86.c | 19 ++++++++++---------
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
Reviewed-by: Paul Durrant <paul@....org>
Powered by blists - more mailing lists