Re: CPU Lockups in KVM with deferred hrtimer rearming

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Apr 23, 2026 at 12:57:49AM +0200, Thomas Gleixner wrote:
> 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 ....

OK, I'll go make this two patches, fix up that comment and post it
proper.