summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/failed-syscalls-by-pid.py
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2025-02-01 04:38:21 +0300
committerSean Christopherson <seanjc@google.com>2025-02-12 21:45:55 +0300
commitca28aa63918b304d77803d5ae952ed875fdad56b (patch)
treef9794492cd52f777cf08b4e9f393ab0b52c041d4 /tools/perf/scripts/python/failed-syscalls-by-pid.py
parent6c4927a4b7b8a2b308f6183cf3d743370419c6b3 (diff)
downloadlinux-ca28aa63918b304d77803d5ae952ed875fdad56b.tar.xz
KVM: x86/xen: Use guest's copy of pvclock when starting timer
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@amazon.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> Link: https://lore.kernel.org/r/20250201013827.680235-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'tools/perf/scripts/python/failed-syscalls-by-pid.py')
0 files changed, 0 insertions, 0 deletions