mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 18:21:39 +01:00
Sergey Dyasli
5ed12565aa
When one core is loading ucode, handling NMI on sibling threads or on other cores in the system might be problematic. By rendezvousing all CPUs in NMI handler, it prevents NMI acceptance during ucode loading. Basically, some work previously done in stop_machine context is moved to NMI handler. Primary threads call in and load ucode in NMI handler. Secondary threads wait for the completion of ucode loading on all CPU cores. An option is introduced to disable this behavior. Control thread doesn't rendezvous in NMI handler by calling self_nmi() (in case of unknown_nmi_error() being triggered). The side effect is control thread might be handling an NMI while other threads are loading ucode. If an ucode is to update something shared by a whole socket, control thread may be accessing things that are being updating by the ucode loading on other cores. It is not safe. Update ucode on the control thread first to mitigate this issue. Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com> Signed-off-by: Chao Gao <chao.gao@intel.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>