From: "tip-bot2 for Sean Christopherson" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>,
Sean Christopherson <seanjc@google.com>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: x86/core] x86/fred: KVM: VMX: Always use FRED for IRQs when CONFIG_X86_FRED=y
Date: Wed, 20 Aug 2025 09:39:05 -0000 [thread overview]
Message-ID: <175568274580.1420.5035691547576445624.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20250714103441.381946911@infradead.org>
The following commit has been merged into the x86/core branch of tip:
Commit-ID: 28d11e4548b75d0960429344f12d5f6cc9cee25b
Gitweb: https://git.kernel.org/tip/28d11e4548b75d0960429344f12d5f6cc9cee25b
Author: Sean Christopherson <seanjc@google.com>
AuthorDate: Thu, 01 May 2025 11:10:39 -07:00
Committer: Peter Zijlstra <peterz@infradead.org>
CommitterDate: Mon, 18 Aug 2025 14:23:08 +02:00
x86/fred: KVM: VMX: Always use FRED for IRQs when CONFIG_X86_FRED=y
Now that FRED provides C-code entry points for handling IRQs, use the
FRED infrastructure for forwarding IRQs even if FRED is fully
disabled, e.g. isn't supported in hardware. Avoiding the non-FRED
assembly trampolines into the IDT handlers for IRQs eliminates the
associated non-CFI indirect call (KVM performs a CALL by doing a
lookup on the IDT using the IRQ vector).
Keep NMIs on the legacy IDT path, as the FRED NMI entry code relies on
FRED's architectural behavior with respect to NMI blocking, i.e. doesn't
jump through the myriad hoops needed to deal with IRET "unexpectedly"
unmasking NMIs. KVM's NMI path already makes a direct CALL to C-code,
i.e. isn't problematic for CFI. KVM does make a short detour through
assembly code to build the stack frame, but the "FRED entry from KVM"
path does the same.
Force FRED for 64-bit kernels if KVM_INTEL is enabled, as the benefits of
eliminating the IRQ trampoline usage far outwieghts the code overhead for
FRED.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20250714103441.381946911@infradead.org
---
arch/x86/kvm/Kconfig | 1 +
arch/x86/kvm/vmx/vmx.c | 8 +++++++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 2c86673..b92ef11 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -97,6 +97,7 @@ config KVM_INTEL
depends on KVM && IA32_FEAT_CTL
select KVM_GENERIC_PRIVATE_MEM if INTEL_TDX_HOST
select KVM_GENERIC_MEMORY_ATTRIBUTES if INTEL_TDX_HOST
+ select X86_FRED if X86_64
help
Provides support for KVM on processors equipped with Intel's VT
extensions, a.k.a. Virtual Machine Extensions (VMX).
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index aa157fe..f7f6c04 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6913,8 +6913,14 @@ static void handle_external_interrupt_irqoff(struct kvm_vcpu *vcpu,
"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.
+ */
kvm_before_interrupt(vcpu, KVM_HANDLING_IRQ);
- if (cpu_feature_enabled(X86_FEATURE_FRED))
+ 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));
next prev parent reply other threads:[~2025-08-20 9:39 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-14 10:20 [PATCH v3 00/16] objtool: Detect and warn about indirect calls in __nocfi functions Peter Zijlstra
2025-07-14 10:20 ` [PATCH v3 01/16] x86/kvm/emulate: Implement test_cc() in C Peter Zijlstra
2025-08-20 9:39 ` [tip: x86/core] KVM: x86: " tip-bot2 for Peter Zijlstra
2025-07-14 10:20 ` [PATCH v3 02/16] x86/kvm/emulate: Introduce EM_ASM_1 Peter Zijlstra
2025-08-20 9:39 ` [tip: x86/core] KVM: x86: " tip-bot2 for Peter Zijlstra
2025-07-14 10:20 ` [PATCH v3 03/16] x86/kvm/emulate: Introduce EM_ASM_2 Peter Zijlstra
2025-08-20 9:39 ` [tip: x86/core] KVM: x86: " tip-bot2 for Peter Zijlstra
2025-07-14 10:20 ` [PATCH v3 04/16] x86/kvm/emulate: Introduce EM_ASM_2R Peter Zijlstra
2025-08-20 9:39 ` [tip: x86/core] KVM: x86: " tip-bot2 for Peter Zijlstra
2025-07-14 10:20 ` [PATCH v3 05/16] x86/kvm/emulate: Introduce EM_ASM_2W Peter Zijlstra
2025-08-20 9:39 ` [tip: x86/core] KVM: x86: " tip-bot2 for Peter Zijlstra
2025-07-14 10:20 ` [PATCH v3 06/16] x86/kvm/emulate: Introduce EM_ASM_2CL Peter Zijlstra
2025-08-20 9:39 ` [tip: x86/core] KVM: x86: " tip-bot2 for Peter Zijlstra
2025-07-14 10:20 ` [PATCH v3 07/16] x86/kvm/emulate: Introduce EM_ASM_1SRC2 Peter Zijlstra
2025-07-24 0:16 ` Sean Christopherson
2025-08-18 10:37 ` Peter Zijlstra
2025-08-20 9:39 ` [tip: x86/core] KVM: x86: " tip-bot2 for Peter Zijlstra
2025-07-14 10:20 ` [PATCH v3 08/16] x86/kvm/emulate: Introduce EM_ASM_3WCL Peter Zijlstra
2025-08-20 9:39 ` [tip: x86/core] KVM: x86: " tip-bot2 for Peter Zijlstra
2025-07-14 10:20 ` [PATCH v3 09/16] x86/kvm/emulate: Convert em_salc() to C Peter Zijlstra
2025-08-20 9:39 ` [tip: x86/core] KVM: x86: " tip-bot2 for Peter Zijlstra
2025-07-14 10:20 ` [PATCH v3 10/16] x86/kvm/emulate: Remove fastops Peter Zijlstra
2025-08-20 9:39 ` [tip: x86/core] KVM: x86: " tip-bot2 for Peter Zijlstra
2025-07-14 10:20 ` [PATCH v3 11/16] x86,hyperv: Clean up hv_do_hypercall() Peter Zijlstra
2025-07-15 4:54 ` Wei Liu
2025-07-15 14:51 ` Michael Kelley
2025-08-20 9:39 ` [tip: x86/core] x86/hyperv: " tip-bot2 for Peter Zijlstra
2025-07-14 10:20 ` [PATCH v3 12/16] x86_64,hyperv: Use direct call to hypercall-page Peter Zijlstra
2025-07-15 4:58 ` Wei Liu
2025-07-15 14:52 ` Michael Kelley
2025-08-18 10:46 ` Peter Zijlstra
2025-08-20 9:39 ` [tip: x86/core] x86/hyperv: " tip-bot2 for Peter Zijlstra
2025-07-14 10:20 ` [PATCH v3 13/16] x86/fred: Install system vector handlers even if FRED isnt fully enabled Peter Zijlstra
2025-08-20 9:39 ` [tip: x86/core] x86/fred: Install system vector handlers even if FRED isn't " tip-bot2 for Sean Christopherson
2025-07-14 10:20 ` [PATCH v3 14/16] x86/fred: Play nice with invoking asm_fred_entry_from_kvm() on non-FRED hardware Peter Zijlstra
2025-07-26 4:54 ` Xin Li
2025-08-18 12:09 ` Peter Zijlstra
2025-08-20 9:39 ` [tip: x86/core] " tip-bot2 for Josh Poimboeuf
2025-07-14 10:20 ` [PATCH v3 15/16] x86/fred: KVM: VMX: Always use FRED for IRQs when CONFIG_X86_FRED=y Peter Zijlstra
2025-08-20 9:39 ` tip-bot2 for Sean Christopherson [this message]
2025-07-14 10:20 ` [PATCH v3 16/16] objtool: Validate kCFI calls Peter Zijlstra
2025-07-14 10:49 ` Peter Zijlstra
2025-07-14 11:21 ` Peter Zijlstra
2025-07-14 16:30 ` Miguel Ojeda
2025-07-15 8:38 ` Peter Zijlstra
2025-07-16 21:03 ` Josh Poimboeuf
2025-07-24 20:37 ` Sean Christopherson
2025-07-25 17:57 ` Xin Li
2025-07-25 19:56 ` Sean Christopherson
2025-07-26 0:33 ` Xin Li
2025-08-20 9:39 ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2025-07-24 20:31 ` [PATCH v3 00/16] objtool: Detect and warn about indirect calls in __nocfi functions Sean Christopherson
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=175568274580.1420.5035691547576445624.tip-bot2@tip-bot2 \
--to=tip-bot2@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=seanjc@google.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;
as well as URLs for NNTP newsgroup(s).