Re: CPU Lockups in KVM with deferred hrtimer rearming

[Thomas Gleixner <tglx@kernel.org>]

On Wed, Apr 22 2026 at 09:46, Peter Zijlstra wrote:
> On Wed, Apr 22, 2026 at 08:55:42AM +0200, Peter Zijlstra wrote:
>> On Tue, Apr 21, 2026 at 02:42:46PM -0700, Sean Christopherson wrote:
>> > On Tue, Apr 21, 2026, Peter Zijlstra wrote:
>> > > On Tue, Apr 21, 2026 at 08:57:24PM +0000, Sean Christopherson wrote:
>> > > > This as delta? (I had typed this all up before Peter posted a new verison, so
>> > > > dammit I'm sending it!)
>> > > 
>> > > :-)
>> > > 
>> > > I'll go stare at it in the morning, I'm about to go crash out.
>> > 
>> > New delta against your effective v2, builds all of my configs (which isn't _that_
>> > many, but I think they cover most of the weirder ways to include KVM (or not)).
>> > 
>> > I'll start testing the full thing to try and get early signal on the health.
>> 
>> Oh, re-reading commit 28d11e4548b7, I think this wrecks NMIs. The patch
>> will also use the FRED NMI path and that's not good when running IDT.
>> 
>> I'll go fix that and stick in a few more comments to clarify this magic.
>
> This should probably we at least two patches, one moving the code into
> the x86 core and one adding that hrtimer fix on top. But kept as one for
> now.
>
> Irrespective of the hrtimer fix, I think the initial move into x86 core
> part is a sane move.

I agree.

> +#if IS_ENABLED(CONFIG_KVM_INTEL)
> +/*
> + * On VMX, NMIs and IRQs (as configured by KVM) are acknowledge by hardware as
> + * part of the VM-Exit, i.e. the event itself is consumed as part the VM-Exit.
> + * x86_entry_from_kvm() is invoked by KVM to effectively forward NMIs and IRQs
> + * to the kernel for servicing.  On SVM, a.k.a. AMD, the NMI/IRQ VM-Exit is
> + * purely a signal that an NMI/IRQ is pending, i.e. the event that triggered
> + * the VM-Exit is held pending until it's unblocked in the host.
> + */
> +noinstr void x86_entry_from_kvm(unsigned int event_type, unsigned int vector)
> +{
> +	if (event_type == EVENT_TYPE_EXTINT) {
> +#ifdef CONFIG_X86_64
> +		/*
> +		 * Use FRED dispatch, even when running IDT. The dispatch
> +		 * tables are kept in sync between FRED and IDT, and the FRED
> +		 * dispatch works well with CFI.
> +		 */
> +		fred_entry_from_kvm(event_type, vector);
> +#else
> +		idt_entry_from_kvm(vector);
> +#endif
> +		/*
> +		 * Strictly speaking, only the NMI path requires noinstr.
> +		 */
> +		instrumentation_begin();
> +		/*
> +		 * KVM/VMX will dispatch from IRQ-disabled but for a context
> +		 * that will have IRQs-enabled. This confuses the entry code
> +		 * and it will not have reprogrammed the timer (or do
> +		 * preemption). Minimal fixup for now.

It's sadly the final fixup.

There is no way that KVM can benefit from the deferred rearm mechanism
in case that NEED_RESCHED is set.

That's actually independent of the VMX specific handle_exit_irqoff()
situation, which obviously cannot reschedule.

The other early local_irq_enable/disable dance, which caused you to buy
a new WTF'o'meter, happens with preemption disabled, so the irq exit
code will do the rearm right there.

So be it ....

Thanks,

        tglx