Userspace uses KVM_CAP_X86_DISABLE_EXITS to enable mwait_in_guest or/andNote, kvm_use_posted_timer_interrupt() uses a heuristic of HLT/MWAIT interceptionCommit 1714a4eb6fb0 gives an explanation:
being disabled to detect that it's worth trying to post a timer interrupt, but off
the top of my head I'm pretty sure that's unnecessary and pointless. The
if only some guests isolated and others not, they would not
have any benefit from posted timer interrupts, and at the same time lose
VMX preemption timer fast paths because kvm_can_post_timer_interrupt()
returns true and therefore forces kvm_can_use_hv_timer() to false.
"vcpu->mode == IN_GUEST_MODE" is super cheap, and I can't think of any harm in
posting the time interrupt if the target vCPU happens to be in guest mode even
if the host wasn't configured just so.
Another scenario I was thinking of was hrtimer expiry during vcpu exitNo, the IRQ won't be delayed. Expiration from the hrtimer callback will set
being handled in KVM/userspace, which will cause timer interrupt
injection after the next exit [1] delaying timer interrupt to guest.
KVM_REQ_UNBLOCK, which will prevent actually entering the guest (see the call
to kvm_request_pending() in kvm_vcpu_exit_request()).
This scenario is not specific to TDX VMs though.
[1] https://git.kernel.org/pub/scm/virt/kvm/kvm.git/tree/arch/x86/kvm/x86.c?h=kvm-coco-queue#n11263