> > > So instead of fixing it, they made it worse :-( > > > > > > And now FRED is arguably making it worse again, and people wonder > > > why I hate virt... > > > > Maybe I take it wrong, but FRED doesn't make anything worse. Fred > > entry code will call external_interrupt() immediately for IRQs. > > But what about NMIs, afaict this is all horribly broken for NMIs. NMIs are NOT handled by external_interrupt(), which is introduced in patch 4. The NMI handling is added to kvm_vmx_reinject_nmi_irq() in patch 5 purely for VMX only. > > So the whole VMX thing latches the NMI (which stops NMI recursion), right? > > But then you drop out of noinstr code, which means any random exception can > happen (kprobes #BP, hw_breakpoint #DB, or even #PF due to random > nonsense like *SAN). This exception will do IRET and clear the NMI latch, all > before you get to run any of the NMI code. > > Note how the normal NMI code is very careful to clear DR7 and both kprobes > and hw_breakpoint know not to accept noinstr code as targets. > > You threw all that out the window. > > Also, NMI is IST, and with FRED it will run on a different stack as well, directly > calling external_interrupt() doesn't honour that either. > > > You really really don't like the context how VMX dispatches NMI/IRQs > > (which has been there for a long time), right? > > I really really hate this with a passion. The fact that it's been this way is no > justification for keeping it. Crap is crap. > > Intel should have taken an example of SVM in this regard, and not doubled > down and extended this NMI hole to regular IRQs. These are exactly the kind of > exception delivery trainwrecks FRED is supposed to fix, except in this case it > appears it doesn't :/
