Re: [PATCH v2 00/36] KVM: VMX APIC timer virtualization support

[Chao Gao <chao.gao@intel.com>]

On Wed, Jul 29, 2026 at 10:39:11AM -0700, Jim Mattson wrote:
>On Wed, Jul 29, 2026 at 3:00 AM Chao Gao <chao.gao@intel.com> wrote:
>>
>> On Tue, Jul 28, 2026 at 11:05:59PM -0700, Jim Mattson wrote:
>> >On Tue, Jul 28, 2026 at 6:35 PM Chao Gao <chao.gao@intel.com> wrote:
>> >>
>> >> Hi Sean, Jim,
>> >>
>> >> Any thoughts on the approach of reusing hv_timer for APIC timer
>> >> virtualization?
>> >
>> >Last I heard, APIC timer virtualization was only available on E-cores,
>> >with no P-core intercept on the roadmap.
>>
>> It will be available on Coral Rapids as well, so it is relevant for
>> server.
>
>That's welcome news!

Thanks for the feedback!

>
>I'm not a fan of the hv_timer approach. One major difference between
>the VMX preemption timer and the virtual TSC deadline MSR is that the
>VMX preemption timer has to be reprogrammed every time that KVM
>switches from hrtimer to hv_timer.

For the preemption timer value written to the VMCS, yes. But
hv_deadline_tsc (the absolute host TSC deadline, set in vmx_set_hv_timer())
doesn't necessarily need recomputation across hrtimer/hv_timer switches.

If this reprogram/recomputation cost matters, we can optimize the
block/unblock path for the preemption timer to avoid that, and then the
same optimization would apply naturally to APIC timer virtualization.

The idea is: don't call cancel_hv_timer() when switching to hrtimer and
don't call set_hv_timer() when switching back. cancel_hv_timer() can
be deferred to virtual interrupt injection time (alongside setting
tscdeadline to 0, which means disarming the timer architecturally).
I think this works for TSC-deadline and oneshot modes; periodic mode
needs more thought since the timer needs to be re-armed after each expiry.

>The virtual TSC deadline timer
>never needs reprogramming during normal operation.

>Another difference
>is that KVM should never inject a virtual local APIC timer interrupt
>when the virtual TSC deadline timer is in use. Even if the vCPU was
>blocked and the hrtimer fired to wake it up, KVM should just let the
>hardware deliver the virtual interrupt on the next VM-entry.

I agree this is the ideal behavior. But I don't see what's wrong with
KVM delivering the interrupt. 

IMO, letting hardware deliver the interrupt after block would require:

  1. We still need to mark the timer as pending to wake the vCPU from
     block. But to let hardware do the injection on VM-entry, we'd
     then need to consume the pending event without actually injecting
     the interrupt.

  2. Tweaking kvm_wait_lapic_expire(). The deadline was advanced when
     arming the hrtimer, so the vCPU wakes slightly before the actual
     deadline. Currently kvm_wait_lapic_expire() scans vIRR to decide
     whether to busy-wait until the deadline, but if we rely on
     hardware to deliver the interrupt, the vector won't be in vIRR
     and we'd need a different indicator.

Given this, I'd prefer to let KVM inject the interrupt for this specific
"hrtimer fired to wakeup" case — it works correctly as is and avoids the
additional complexity.

>
>I'd rather see TSC deadline timer virtualization implemented as a
>standalone APIC virtualization feature.