Re: CPU Lockups in KVM with deferred hrtimer rearming

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Apr 21, 2026 at 08:57:24PM +0000, Sean Christopherson wrote:

> > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > new file mode 100644
> > index 000000000000..4b0171abb083
> > --- /dev/null
> > +++ b/arch/x86/entry/common.c
> > @@ -0,0 +1,22 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +
> > +#include <linux/kvm_types.h>
> > +#include <linux/hrtimer_rearm.h>
> 
> For CONFIG_X86_FRED=n, which is possible on x86-64 if CONFIG_KVM_INTEL=n, this
> 
> #include <linux/sched/task_stack.h>
> 
> is needed so that task_pt_regs() can find task_stack_page() (and including
> task_stack.h in processor.h would create cyclical includes).
> 
> > +#include <asm/entry-common.h>

This wanted to be linux/entry-common.h, otherwise I could not get 32bit
to build. And that sorts that same include issue you pointed out. My
x86_64 build didn't seem to care...

> > +#include <asm/fred.h>
> > +#include <asm/desc.h>
> > +
> 
> Related to CONFIG_X86_FRED=n, I vote to wrap this API with #if IS_ENABLED(CONFIG_KVM_INTEL)
> and then delete the fred_entry_from_kvm() stub so that a goof results in a build
> failure.  That'd also be a good place for a comment to explain some of the usage.

Yeah, it definitely wants a few comments. I'll do the KVM_INTEL thing,
I'd forgotten we'd made the FRED=y thing conditinoal on that, I thought
we'd had it unconditionally =y for 64bit.


> 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.