Re: CPU Lockups in KVM with deferred hrtimer rearming

[Thomas Gleixner <tglx@kernel.org>]

On Wed, Apr 22 2026 at 00:15, Paolo Bonzini wrote:
> On Tue, Apr 21, 2026 at 11:48 PM Thomas Gleixner <tglx@kernel.org> wrote:
>> On Tue, Apr 21 2026 at 21:39, Paolo Bonzini wrote:
>> > ... it's not decades, ack on VM exit is actually relatively recent (10
>> > years out 20 :)). The reason why it was introduced is another killer
>> > for the idea, though. Posted interrupts require it, for some reason
>> > only known to Intel.
>>
>> That's yet another attempt to provide an halfways decent argument, but
>> as anything else related to KVM/VIRT it is neither documented nor proven
>> to be true.
>
> SDM, "27.2.1 Checks on VMX Controls", under "VM-Execution Control Fields":
>
> If the “process posted interrupts” VM-execution control is 1, the
> following must be true: [...]
> — The “acknowledge interrupt on exit” VM-exit control is 1.
>
> I grant you the "not documented" (not cross referenced to the manual
> in commit 01e439be775) part, but "not proven to be true"? Neither I
> nor my predecessors are *that* clueless.

I did not claim at all that you or your predecessors are clueless, but
do I really have to do all the homework which you and them obviously
failed to do?

And even now in this discussion you came only forth with a real
explanation after I told you that it's nowhere documented in the kernel
code or the related changelogs.

Still now you tell me that 01e439be775 is the key to all of this, which
is completely irrelevant because the commit which started to violate the
core kernel code semantics and expectations is f2485b3e0c6c ("KVM: x86:
use guest_exit_irqoff") which happened _three_ years _after_ 01e439be775
introduced the detection of posted interrupts.

Do you really expect me to connect the useless changelog of f2485b3e0c6c
to the posted interrupts restrictions which are not mentioned anywhere?

> Is reading the manual enough?

Are you seriously asking me to read the manual to figure out why some
completely undocumented code exists? And then deduce why that code
violates basic principles of the core code assumptions which have been
there way _before_ any of this x86 virtualization gunk even existed on a
napkin sketch?

You are putting the cart before the horse.

KVM is violating basic principles without giving any clue to those who
try to keep them maintained. Neither in changelogs nor in code nor in
comments.

Please don't misunderstand me. I'm not trying to fingerpoint here. I'm
trying to understand how we got into this mess and what's the proper way
out of it.

At least after tons of useless wasted cycles/emails I know now that
there seems to be some real existing hardware constraint.

As a consequence I'll go and use the irq_regs workaround in
hrtimer_interrupt_rearm() for now. It's not pretty, but as I pointed out
before, it _is_ covering _all_ (even not yet discovered) KVM/VIRT
induced violations of core code semantics and expectations in one go and
it is pretty much performance neutral for the price that the KVM/VMX
host side can't take advantage of it.

If KVM/VMX want's to benefit from the semantically correct
hrtimer/HRTICK related core code improvements, then please post patches
which might hit the 7.2 merge window eventually in case they make sense
and most importantly are semantically correct.

Thanks,

        tglx