diff options
| author | Sean Christopherson <seanjc@google.com> | 2025-08-05 12:05:13 -0700 |
|---|---|---|
| committer | Sean Christopherson <seanjc@google.com> | 2025-08-19 11:59:34 -0700 |
| commit | 0a94b2042419f7896f5d362465731506e43bc319 (patch) | |
| tree | b9ef8efca45941d252a81c15d8c27d537b5adf4a /scripts/bpf_doc.py | |
| parent | aeeb4c7fff525e0fd71ec28162b713b8cb1ec943 (diff) | |
KVM: x86: Unconditionally handle MSR_IA32_TSC_DEADLINE in fastpath exits
Drop the fastpath VM-Exit requirement that KVM can use the hypervisor
timer to emulate the APIC timer in TSC deadline mode. I.e. unconditionally
handle MSR_IA32_TSC_DEADLINE WRMSRs in the fastpath. Restricting the
fastpath to *maybe* using the VMX preemption timer is ineffective and
unnecessary.
If the requested deadline can't be programmed into the VMX preemption
timer, KVM will fall back to hrtimers, i.e. the restriction is ineffective
as far as preventing any kind of worst case scenario.
But guarding against a worst case scenario is completely unnecessary as
the "slow" path, start_sw_tscdeadline() => hrtimer_start(), explicitly
disables IRQs. In fact, the worst case scenario is when KVM thinks it
can use the VMX preemption timer, as KVM will eat the overhead of calling
into vmx_set_hv_timer() and falling back to hrtimers.
Opportunistically limit kvm_can_use_hv_timer() to lapic.c as the fastpath
code was the only external user.
Stating the obvious, this allows handling MSR_IA32_TSC_DEADLINE writes in
the fastpath on AMD CPUs.
Link: https://lore.kernel.org/r/20250805190526.1453366-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'scripts/bpf_doc.py')
0 files changed, 0 insertions, 0 deletions
