Re: [Xen-devel] [PATCH v1 2/4] x86/microcode: Improve parsing for ucode=

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.01.2020 23:30, Eslam Elnikety wrote:
> Decouple the microcode indexing mechanism when using GRUB to that
> when using EFI. This allows us to avoid the "unspecified effect" of
> using `<integer>` when booting via EFI.

Personally I'd prefer us to continue call this unspecified. It
simply shouldn't be used. People shouldn't rely on it getting
ignored. (Iirc, despite this being v1, you had previously
submitted a patch to this effect, with me replaying about the
same.)

> With that, Xen can explicitly ignore that option when using EFI.

Don't we do so already, by way of the "if ( !ucode_mod_forced )"
you delete?

> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2147,9 +2147,9 @@ for updating CPU micrcode. When negative, counting 
> starts at the end of
>  the modules in the GrUB entry (so with the blob commonly being last,
>  one could specify `ucode=-1`). Note that the value of zero is not valid
>  here (entry zero, i.e. the first module, is always the Dom0 kernel
> -image). Note further that use of this option has an unspecified effect
> -when used with xen.efi (there the concept of modules doesn't exist, and
> -the blob gets specified via the `ucode=<filename>` config file/section
> +image). This option should be used only with legacy boot, as it is explicitly
> +ignored in EFI boot. When booting via EFI, the microcode update blob for
> +early loading can be specified via the `ucode=<filename>` config file/section
>  entry; see [EFI configuration file description](efi.html)).

Just like in patch 1, please distinguish "EFI boot" in general from
"use of xen.efi" (relevant here of course only if indeed we went
with this patch).

Jan

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