Re: CPU Lockups in KVM with deferred hrtimer rearming

Paolo Bonzini
2026-04-21T22:25:02Z

On Tue, Apr 21, 2026 at 10:49 PM Thomas Gleixner <tglx@kernel.org> wrote:
> This got changed by f2485b3e0c6c ("KVM: x86: use guest_exit_irqoff") in
> June 2016 to save an completely unspecified amount of 'few cycles'.

Sean answered in way too much detail :) but since I was about to do it
too that is a local_irq_save/restore pair, so 20-50 cycles per vmexit.
Nowadays, due to the overhead from mitigating side channel attacks,
the cost of vmexits went up from ~1000 clock cycles to (depending on
your settings) even 2500-3000.

Back when posted interrupt support was added, "ack intr on exit" was
always used when available, but was optional. In 2016 I made it
mandatory. The micro-optimization at the time had a consistent 2-3%
gain on some benchmarks like UDP_RR, but also on realistic workloads
with lots of thread wakeups; the simplification was also a nice bonus,
but these days this part is almost negligible these days.

However the optimization that Sean remembered is only a small part of
the story. The real issue is that "ack intr on exit" is a requirement
for posted intr support. For each interrupt from assigned devices, it
saves a full vmexit/vmentry for the vCPU. Adding the extra latency
from processing the interrupt, writing to the eventfd and triggering
the vmexit, that's at least a couple microseconds in total. That's two
orders of magnitude more than the "few cycles" that commit
f2485b3e0c6c added on top.

The reference to TDX is not clear to me either, but I am probably
missing something obvious because it's a bit late here.

Paolo

> You really want to come up with real numbers which prove the performance
> benefit to justify the extra complexity of this.