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

[Chao Gao]

Hi Sean, Jim,

Any thoughts on the approach of reusing hv_timer for APIC timer
virtualization?

On Thu, Jul 16, 2026 at 04:30:57PM +0800, Chao Gao wrote:
>On Thu, Mar 05, 2026 at 09:43:40AM -0800, isaku.yamahata@xxxxxxxxx wrote:
>>From: Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
>>
>>This patch series is v2 of VMX APIC timer virtualization support.
>
>Hi,
>
>I'm picking up the APIC timer virtualization work that Isaku posted [1].
>While reviewing the series, I noticed that APIC timer virtualization and
>the VMX preemption timer share fundamental properties:
>
>  - Both run only in guest mode, requiring KVM to switch to a software
>    hrtimer when the vCPU blocks.
>  - Both are armed/disarmed by writing a VMCS field (a countdown for the
>    preemption timer, an absolute TSC deadline for APIC timer
>    virtualization).
>
>These are exactly the properties the existing hv_timer infrastructure
>was designed for. This v2 series treats APIC timer virtualization as
>an entirely new mechanism, introducing a separate apic_virt_timer_in_use
>flag with five dedicated hooks and helpers to arm/disarm and manage state
>transitions in the common x86 flows (see [2]). I think we can avoid that.
>
>The idea is to reuse set_hv_timer()/cancel_hv_timer() for APIC timer
>virtualization, with two additions:
>
>First, the pieces specific to APIC timer virtualization:
>
>  - Configure the timer interrupt vector in the VMCS.
>  - Disable MSR interception for TSC_DEADLINE when the guest is in
>    deadline mode (so writes go directly to hardware).
>  - Re-enable interception when the guest leaves deadline mode or masks
>    the timer.
>
>These are naturally scoped to LVTT register writes, so a single
>update_lvtt() vendor hook is sufficient.
>
>Second, tracking the timer state. With the preemption timer, KVM
>intercepts every MSR_IA32_TSC_DEADLINE write and knows precisely when a
>timer is armed. With APIC timer virtualization, the MSR is not
>intercepted and the guest arms and re-arms the timer without KVM's
>knowledge. When the vCPU halts, KVM needs to know whether a timer is
>armed and its deadline to set up the software wakeup timer.
>
>The solution is straightforward: on VM-exit, read back the deadline from
>the VMCS and update KVM's existing tracking (hv_timer_in_use and
>ktimer->tscdeadline). This is one vmcs_read64() per VM-exit, negligible
>compared to the exit cost itself. The existing vcpu_block() path then
>works unchanged.
>
>I prototyped this approach [3] for enabling APIC timer virtualization for
>L1 guests (nested support isn't considered). The result is roughly a third
>of the code (110 LoC vs. 300 LoC), with details of hypervisor timers
>(preemption timer or APIC timer virtualization) fully contained in VMX. The
>only change to common x86 code is a single kvm_x86_call in apic_update_lvtt().
>
>I plan to post a series based on this approach and would appreciate
>feedback on the direction before doing so.
>
>Thanks,
>Chao
>
>[1] https://lore.kernel.org/kvm/cover.1772732517.git.isaku.yamahata@xxxxxxxxx/
>[2] https://lore.kernel.org/kvm/727502c8f79850fae6a8a476a624e5902861db39.1772732517.git.isaku.yamahata@xxxxxxxxx/
>[3] https://github.com/gaochaointel/linux-dev/commits/43056263022fe57cc9a10ebf2828f0f29611d6c