public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Binbin Wu <binbin.wu@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: tglx@kernel.org, linux-kernel@vger.kernel.org,
	Sean Christopherson <seanjc@google.com>,
	Jim Mattson <jmattson@google.com>,
	Vishal L Verma <vishal.l.verma@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Rick P Edgecombe <rick.p.edgecombe@intel.com>,
	Binbin Wu <binbin.wu@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	Paolo Bonzini <bonzini@redhat.com>
Subject: Re: [PATCH 1/2] x86/kvm/vmx: Move IRQ/NMI dispatch from KVM into x86 core
Date: Tue, 28 Apr 2026 17:43:58 +0800	[thread overview]
Message-ID: <e47f29d5-17f1-47ce-b80e-bfa543f9a712@linux.intel.com> (raw)
In-Reply-To: <20260423155936.843498069@infradead.org>



On 4/23/2026 11:56 PM, Peter Zijlstra wrote:
> Move the VMX interrupt dispatch magic into the x86 core code. This
> isolates KVM from the FRED/IDT decisions and reduces the amount of
> EXPORT_SYMBOL_FOR_KVM().
> 
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Tested-by: "Verma, Vishal L" <vishal.l.verma@intel.com>
> ---
>  arch/x86/entry/Makefile             |    2 -
>  arch/x86/entry/common.c             |   48 ++++++++++++++++++++++++++++++++++++
>  arch/x86/entry/entry.S              |   46 ++++++++++++++++++++++++++++++++++
>  arch/x86/entry/entry_64_fred.S      |    1 
>  arch/x86/include/asm/desc.h         |    4 +++
>  arch/x86/include/asm/desc_defs.h    |    2 -
>  arch/x86/include/asm/entry-common.h |    2 +
>  arch/x86/include/asm/fred.h         |    1 
>  arch/x86/include/asm/idtentry.h     |   11 --------
>  arch/x86/kernel/idt.c               |   13 +++++++++
>  arch/x86/kernel/nmi.c               |    8 ------
>  arch/x86/kvm/vmx/vmenter.S          |   46 ----------------------------------
>  arch/x86/kvm/vmx/vmx.c              |   20 ++-------------
>  13 files changed, 118 insertions(+), 86 deletions(-)
> 
> --- a/arch/x86/entry/Makefile
> +++ b/arch/x86/entry/Makefile
> @@ -13,7 +13,7 @@ CFLAGS_REMOVE_syscall_64.o	= $(CC_FLAGS_
>  CFLAGS_syscall_32.o		+= -fno-stack-protector
>  CFLAGS_syscall_64.o		+= -fno-stack-protector
>  
> -obj-y				:= entry.o entry_$(BITS).o syscall_$(BITS).o
> +obj-y				:= entry.o entry_$(BITS).o syscall_$(BITS).o common.o
>  
>  obj-y				+= vdso/
>  obj-y				+= vsyscall/
> --- /dev/null
> +++ b/arch/x86/entry/common.c
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#include <linux/entry-common.h>
> +#include <linux/kvm_types.h>
> +#include <asm/fred.h>
> +#include <asm/desc.h>
> +
> +#if IS_ENABLED(CONFIG_KVM_INTEL)
> +/*
> + * On VMX, NMIs and IRQs (as configured by KVM) are acknowledge by hardware as

s/acknowledge/acknowledged
 
> + * 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.
> + */

[...]

> -
> -#if IS_ENABLED(CONFIG_KVM_INTEL)
> -/*
> - * Special entry point for VMX which invokes this on the kernel stack, even for
> - * 64-bit, i.e. without using an IST.  asm_exc_nmi() requires an IST to work

Although it's being removed, I guess what it says is still true?

It says asm_exc_nmi() requires an IST to work correctly, and the new path for
handling NMI when FRED is disabled.

idt_entry_from_kvm
    idt_do_nmi_irqoff
        IDT_DO_EVENT_IRQOFF call asm_exc_nmi
            ...
            call asm_exc_nmi

It seems the stack before calling asm_exc_nmi is not an IST?
Does it matter?

> - * correctly vs. the NMI 'executing' marker.  Used for 32-bit kernels as well
> - * to avoid more ifdeffery.
> - */
> -DECLARE_IDTENTRY(X86_TRAP_NMI,		exc_nmi_kvm_vmx);
> -#endif
> -
>  DECLARE_IDTENTRY_NMI(X86_TRAP_NMI,	exc_nmi);
>  #ifdef CONFIG_XEN_PV
>  DECLARE_IDTENTRY_RAW(X86_TRAP_NMI,	xenpv_exc_nmi);

[...]

> @@ -7127,17 +7124,9 @@ static void handle_external_interrupt_ir
>  	    "unexpected VM-Exit interrupt info: 0x%x", intr_info))
>  		return;
>  
> -	/*
> -	 * Invoke the kernel's IRQ handler for the vector.  Use the FRED path
> -	 * when it's available even if FRED isn't fully enabled, e.g. even if
> -	 * FRED isn't supported in hardware, in order to avoid the indirect
> -	 * CALL in the non-FRED path.
> -	 */
> +	/* For the IRQ to the core kernel for processing. */

For -> Forward?

>  	kvm_before_interrupt(vcpu, KVM_HANDLING_IRQ);
> -	if (IS_ENABLED(CONFIG_X86_FRED))
> -		fred_entry_from_kvm(EVENT_TYPE_EXTINT, vector);
> -	else
> -		vmx_do_interrupt_irqoff(gate_offset((gate_desc *)host_idt_base + vector));
> +	x86_entry_from_kvm(EVENT_TYPE_EXTINT, vector);
>  	kvm_after_interrupt(vcpu);
>  
>  	vcpu->arch.at_instruction_boundary = true;
> @@ -7447,10 +7436,7 @@ noinstr void vmx_handle_nmi(struct kvm_v
>  		return;
>  
>  	kvm_before_interrupt(vcpu, KVM_HANDLING_NMI);
> -	if (cpu_feature_enabled(X86_FEATURE_FRED))
> -		fred_entry_from_kvm(EVENT_TYPE_NMI, NMI_VECTOR);
> -	else
> -		vmx_do_nmi_irqoff();
> +	x86_entry_from_kvm(EVENT_TYPE_NMI, NMI_VECTOR);
>  	kvm_after_interrupt(vcpu);
>  }
>  
> 
> 
> 


  parent reply	other threads:[~2026-04-28  9:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-23 15:56 [PATCH 0/2] x86/kvm/vmx: Fix VMX interrupt injection vs hrtimer_rearm_deferred() Peter Zijlstra
2026-04-23 15:56 ` [PATCH 1/2] x86/kvm/vmx: Move IRQ/NMI dispatch from KVM into x86 core Peter Zijlstra
2026-04-23 17:54   ` Xin Li
2026-04-28  9:43   ` Binbin Wu [this message]
2026-04-28 11:25     ` Paolo Bonzini
2026-05-01 20:31       ` Peter Zijlstra
2026-05-01 20:37   ` [PATCH v2 " Peter Zijlstra
2026-04-23 15:56 ` [PATCH 2/2] x86/kvm/vmx: Fix VMX vs hrtimer_rearm_deferred() Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e47f29d5-17f1-47ce-b80e-bfa543f9a712@linux.intel.com \
    --to=binbin.wu@linux.intel.com \
    --cc=binbin.wu@intel.com \
    --cc=bonzini@redhat.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@kernel.org \
    --cc=vishal.l.verma@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox