On Wed, Jan 22, 2025, Frederic Weisbecker wrote:
> Le Tue, Jan 14, 2025 at 06:51:35PM +0100, Valentin Schneider a écrit :
> > ct_nmi_{enter, exit}() only touches the RCU watching counter and doesn't
> > modify the actual CT state part context_tracking.state. This means that
> > upon receiving an IRQ when idle, the CT_STATE_IDLE->CT_STATE_KERNEL
> > transition only happens in ct_idle_exit().
> >
> > One can note that ct_nmi_enter() can only ever be entered with the CT state
> > as either CT_STATE_KERNEL or CT_STATE_IDLE, as an IRQ/NMI happenning in the
> > CT_STATE_USER or CT_STATE_GUEST states will be routed down to ct_user_exit().
>
> Are you sure? An NMI can fire between guest_state_enter_irqoff() and
> __svm_vcpu_run().
Heh, technically, they can't. On SVM, KVM clears GIF prior to svm_vcpu_enter_exit(),
and restores GIF=1 only after it returns. I.e. NMIs are fully blocked _on SVM_.
VMX unfortunately doesn't provide GIF, and so NMIs can arrive at any time. It's
infeasible for software to prevent them, so we're stuck with that. [In theory,
KVM could deliberately generate an NMI and not do IRET so that NMIs are blocked,
but that would be beyond crazy].
> And NMIs interrupting userspace don't call enter_from_user_mode(). In fact
> they don't call irqentry_enter_from_user_mode() like regular IRQs but
> irqentry_nmi_enter() instead. Well that's for archs implementing common entry
> code, I can't speak for the others.
>
> Unifying the behaviour between user and idle such that the IRQs/NMIs exit the
> CT_STATE can be interesting but I fear this may not come for free. You would
> need to save the old state on IRQ/NMI entry and restore it on exit.
>
> Do we really need it?
>
> Thanks.
