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....@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
