> > Like IRET for IDT, ERETS/ERETU are required to end the NMI handler for > > FRED to unblock NMI ASAP (w/ bit 28 of CS set). > > That's "CS" on the stack correct? Is bit 28 set manually by software, or is it set > automatically by hardware? If it's set by hardware, does "int $2" actually set the > bit since it's not a real NMI? Right, It's the "CS" on the stack. The bit 28 is set by the FRED NMI handler: https://lore.kernel.org/lkml/20230307023946.14516-20-xin3.li@xxxxxxxxx/ Upon a NMI delivery, the NMI bit is always set by H/W. However, "int $2" does NOT set it, thus we need to explicitly set it. > > And there are 2 approaches to > > invoke the FRED NMI handler: > > 1) execute "int $2", let the h/w do the job. > > 2) create a FRED NMI stack frame on the current kernel stack with ASM, > > and then jump to fred_entrypoint_kernel in arch/x86/entry/entry_64_fred.S. > > > > 1) is preferred as we want less ASM. > > Who is "we", and how much assembly are we talking about? E.g. I personally don't > mind a trampoline in KVM if it's small and/or can share code with existing assembly > subroutines. I ever got such a comment: https://lore.kernel.org/lkml/8735bpbhat.ffs@tglx/ However, if ASM is also okay, I can work on it. And I don't think the ASM code will be big.
