Something like so... except this is broken. Its reporting spurious interrupts on vector 0x00, so something is buggered passing that vector along.
I'm a bit late to the party :) Peter kind of got what I had in the FRED patch set v8 or earlier: https://lore.kernel.org/lkml/20230410081438.1750-34-xin3.li@xxxxxxxxx/
Uh, aren't you making this way more complex than it needs to be? IIUC, KVM never uses the FRED hardware entry points, i.e. the FRED entry tables don't need to be in place because they'll never be used. The only bits of code KVM needs is the __fred_entry_from_kvm() glue.
+1
Lightly tested, but this combo works for IRQs and NMIs on non-FRED hardware. -- From 664468143109ab7c525c0babeba62195fa4c657e Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc@xxxxxxxxxx> Date: Thu, 1 May 2025 11:20:29 -0700 Subject: [PATCH 1/2] x86/fred: Play nice with invoking asm_fred_entry_from_kvm() on non-FRED hardware Modify asm_fred_entry_from_kvm() to allow it to be invoked by KVM even when FRED isn't fully enabled, e.g. when running with CONFIG_X86_FRED=y on non-FRED hardware. This will allow forcing KVM to always use the FRED entry points for 64-bit kernels, which in turn will eliminate a rather gross non-CFI indirect call that KVM uses to trampoline IRQs by doing IDT lookups. When FRED isn't enabled, simply skip ERETS and restore RBP and RSP from the stack frame prior to doing a "regular" RET back to KVM (in quotes because of all the RET mitigation horrors). Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx> --- arch/x86/entry/entry_64_fred.S | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/entry/entry_64_fred.S b/arch/x86/entry/entry_64_fred.S index 29c5c32c16c3..7aff2f0a285f 100644 --- a/arch/x86/entry/entry_64_fred.S +++ b/arch/x86/entry/entry_64_fred.S @@ -116,7 +116,8 @@ SYM_FUNC_START(asm_fred_entry_from_kvm) movq %rsp, %rdi /* %rdi -> pt_regs */ call __fred_entry_from_kvm /* Call the C entry point */ POP_REGS - ERETS + + ALTERNATIVE "", __stringify(ERETS), X86_FEATURE_FRED
Neat! I ever had a plan to do this with "sub $0x8,%rsp; iret;" for non-FRED case. But obviously doing nothing here is the best.
1: /* * Objtool doesn't understand what ERETS does, this hint tells it that @@ -124,7 +125,7 @@ SYM_FUNC_START(asm_fred_entry_from_kvm) * isn't strictly needed, but it's the simplest form. */ UNWIND_HINT_RESTORE - pop %rbp + leave
This is a smart change. When !X86_FEATURE_FRED, the FRED stack frame set up for ERETS is implicitly skipped by leave. Maybe add a comment to explain LEAVE works for both cases?
