summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorDavid Woodhouse <dwmw@amazon.co.uk>2026-08-26 14:32:56 -0700
committerSean Christopherson <seanjc@google.com>2026-09-11 11:46:19 -0700
commit92fac63cc73920175f712cec792f9ab698923ffb (patch)
treef8addbf20309f7b2f12d72aa75ef26f8253569f3 /tools/perf/scripts/python
parentf21b04302404fa87826caa7f5fd3f7e07ab6782e (diff)
KVM: x86: Upscale TSC to "now", not master clock when updating PV clocks
When doing TSC upscaling in software, e.g. when the guest TSC frequency is configured to run faster than the host without hardware support, always advance guest TSC to "now", not to the master clock's reference values, which represents some time in the past. In master clock mode, there are two points of time which need to be taken into account. First there is the master clock reference point, stored in kvm->arch.master_kernel_ns (and associated host TSC ->master_cycle_now). Secondly, there is the time *now*, at the point kvm_update_guest_time() is being called. With software TSC upscaling, the guest TSC is getting further and further ahead of the host TSC as time elapses. So at time "now", the guest TSC should be further ahead of the host, than it was at master_kernel_ns. Not taking that into account means KVM was advancing the guest TSC only by the amount appropriate for the snapshot taken in the past, *not* to the current time (which is what RDTSC is supposed to return). Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Co-developed-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20260826213303.914988-17-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions