On Fri, May 02, 2025, Peter Zijlstra wrote: > On Thu, May 01, 2025 at 11:30:18AM -0700, Sean Christopherson wrote: > > > Uh, aren't you making this way more complex than it needs to be? > > Possibly :-) > > > 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. > > But __fred_entry_from_kvm() calls into fred_extint(), which then > directly uses the fred sysvec_table[] for dispatch. How would we not > have to set up that table? I missed that the first time around. From my self-reply: : Hrm, and now I see that fred_extint() relies on fred_install_sysvec(), which makes : me quite curious as to why IRQs didn't go sideways. Oh, because sysvec_table[] : is statically defined at compile time except for PV crud. : : So yeah, I think my the patches are correct, they just the need a small bit of : prep work to support dynamic setup of sysvec_table. > > Lightly tested, but this combo works for IRQs and NMIs on non-FRED hardware. > > So the FRED NMI code is significantly different from the IDT NMI code > and I really didn't want to go mixing those. > > If we get a nested NMI I don't think it'll behave well. Ah, because FRED hardwware doesn't have the crazy NMI unblocking behavior, and the FRED NMI entry code relies on that. But I don't see why we need to care about NMIs from KVM, while they do bounce through assembly to create a stack frame, the actual CALL is direct to asm_exc_nmi_kvm_vmx(). If it's just the unwind hint that's needed, that The attached patches handle the IRQ case and are passing my testing.
