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

From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: Chao Gao <chao.gao@intel.com>, <xen-devel@lists.xenproject.org>
Cc: "sergey.dyasli@citrix.com >> Sergey Dyasli"
	<sergey.dyasli@citrix.com>, "Ashok Raj" <ashok.raj@intel.com>,
	"Wei Liu" <wl@xen.org>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v9 15/15] microcode: block #NMI handling when loading an ucode
Date: Fri, 23 Aug 2019 09:46:37 +0100	[thread overview]
Message-ID: <3b455c41-b5a3-2533-99a8-2200def4b19f@citrix.com> (raw)
In-Reply-To: <1566177928-19114-16-git-send-email-chao.gao@intel.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