| Message ID | 20250201013827.680235-8-seanjc@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: x86: pvclock fixes and cleanups | expand |
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@amazon.com> > Cc: David Woodhouse <dwmw@amazon.co.uk> > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > arch/x86/kvm/x86.c | 19 ++++++++++--------- > 1 file changed, 10 insertions(+), 9 deletions(-) > Reviewed-by: Paul Durrant <paul@xen.org>
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 3971a13bddbe..5f3ad13a8ac7 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3262,20 +3262,21 @@ static int kvm_guest_time_update(struct kvm_vcpu *v) if (use_master_clock) vcpu->hv_clock.flags |= PVCLOCK_TSC_STABLE_BIT; - if (vcpu->pv_time.active -#ifdef CONFIG_KVM_XEN - || vcpu->xen.vcpu_info_cache.active - || vcpu->xen.vcpu_time_info_cache.active -#endif - ) { + if (vcpu->pv_time.active) { + /* + * GUEST_STOPPED is only supported by kvmclock, and KVM's + * historic behavior is to only process the request if kvmclock + * is active/enabled. + */ if (vcpu->pvclock_set_guest_stopped_request) { vcpu->hv_clock.flags |= PVCLOCK_GUEST_STOPPED; vcpu->pvclock_set_guest_stopped_request = false; } - } - - if (vcpu->pv_time.active) kvm_setup_guest_pvclock(v, &vcpu->pv_time, 0, false); + + vcpu->hv_clock.flags &= ~PVCLOCK_GUEST_STOPPED; + } + #ifdef CONFIG_KVM_XEN if (vcpu->xen.vcpu_info_cache.active) kvm_setup_guest_pvclock(v, &vcpu->xen.vcpu_info_cache,
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@amazon.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Sean Christopherson <seanjc@google.com> --- arch/x86/kvm/x86.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-)