aboutsummaryrefslogtreecommitdiffstats
path: root/tools/testing/selftests/net/lib/py/utils.py
diff options
context:
space:
mode:
authorSean Christopherson <[email protected]>2025-02-01 01:38:23 +0000
committerSean Christopherson <[email protected]>2025-02-12 18:45:55 +0000
commit93fb0b10e7121f3be86c4cdd564d7e1c0974deca (patch)
treee6bcc31c8334ba6fc09500d6534802d13533734f /tools/testing/selftests/net/lib/py/utils.py
parentKVM: x86: Don't bleed PVCLOCK_GUEST_STOPPED across PV clocks (diff)
downloadkernel-93fb0b10e7121f3be86c4cdd564d7e1c0974deca.tar.gz
kernel-93fb0b10e7121f3be86c4cdd564d7e1c0974deca.zip
KVM: x86: Set PVCLOCK_GUEST_STOPPED only for kvmclock, not for Xen PV clock
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 <[email protected]> Cc: David Woodhouse <[email protected]> Reviewed-by: Paul Durrant <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]>
Diffstat (limited to 'tools/testing/selftests/net/lib/py/utils.py')
0 files changed, 0 insertions, 0 deletions