Re: [Xen-devel] [PATCH v9 15/15] microcode: block #NMI handling when loading an ucode

[Sergey Dyasli <sergey.dyasli@citrix.com>]

On 19/08/2019 02:25, Chao Gao wrote:
> register an nmi callback. And this callback does busy-loop on threads
> which are waiting for loading completion. Control threads send NMI to
> slave threads to prevent NMI acceptance during ucode loading.
> 
> Signed-off-by: Chao Gao <chao.gao@intel.com>
> ---
> Changes in v9:
>  - control threads send NMI to all other threads. Slave threads will
>  stay in the NMI handling to prevent NMI acceptance during ucode
>  loading. Note that self-nmi is invalid according to SDM.

To me this looks like a half-measure: why keep only slave threads in
the NMI handler, when master threads can update the microcode from
inside the NMI handler as well?

You mention that self-nmi is invalid, but Xen has self_nmi() which is
used for apply_alternatives() during boot, so can be trusted to work.

I experimented a bit with the following approach: after loading_state
becomes LOADING_CALLIN, each cpu issues a self_nmi() and rendezvous
via cpu_callin_map into LOADING_ENTER to do a ucode update directly in
the NMI handler. And it seems to work.

Separate question is about the safety of this approach: can we be sure
that a ucode update would not reset the status of the NMI latch? I.e.
can it cause another NMI to be delivered while Xen already handles one?

>  - s/rep_nop/cpu_relax
>  - remove debug message in microcode_nmi_callback(). Printing debug
>  message would take long times and control thread may timeout.
>  - rebase and fix conflicts

Thanks,
Sergey

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel