Specify applicability and the default value. Also state that, in case of EFI, the microcode update blob specified in the EFI cfg takes precedence over `ucode=scan`, if the latter is specified on Xen commend line.
No functional changes. Signed-off-by: Eslam Elnikety <elnik...@amazon.com> --- docs/misc/xen-command-line.pandoc | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 981a5e2381..ebec6d387e 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2134,7 +2134,12 @@ logic applies: ### ucode (x86) > `= List of [ <integer> | scan=<bool>, nmi=<bool> ]` -Specify how and where to find CPU microcode update blob. + Applicability: x86 + Default: `nmi` + +Controls for CPU microcode loading. For early loading, this parameter can +specify how and where to find the microcode update blob. For late loading, +this parameter specifies if the update happens within a NMI handler. 'integer' specifies the CPU microcode update blob module index. When positive, this specifies the n-th module (in the GrUB entry, zero based) to be used @@ -2152,6 +2157,7 @@ image that contains microcode. Depending on the platform the blob with the microcode in the cpio name space must be: - on Intel: kernel/x86/microcode/GenuineIntel.bin - on AMD : kernel/x86/microcode/AuthenticAMD.bin +If EFI boot, the `ucode=<filename>` config takes precendence over `scan`. 'nmi' determines late loading is performed in NMI handler or just in stop_machine context. In NMI handler, even NMIs are blocked, which is -- 2.17.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
