[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/microcode: Support builtin CPU microcode



On 11.12.19 10:54, Jan Beulich wrote:
On 11.12.2019 00:18, Eslam Elnikety wrote:
On 10.12.19 10:37, Jan Beulich wrote:
On 09.12.2019 09:41, Eslam Elnikety wrote:
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2113,7 +2113,7 @@ logic applies:
      active by default.
### ucode (x86)
-> `= List of [ <integer> | scan=<bool>, nmi=<bool> ]`
+> `= List of [ <integer> | scan=<bool> | builtin=<bool>, nmi=<bool> ]`

Despite my other question regarding the usefulness of this as a
whole a few comments.

Do "scan" and "builtin" really need to exclude each other? I.e.
don't you mean , instead of | ?
The useful case here would be specifying ucode=scan,builtin which would
translate to fallback onto the builtin microcode if a scan fails. In
fact, this is already the case given the implementation in v1. It will
be better to clarify this semantic by allowing scan,builtin.

On that note, I really see the "<integer>" and "scan=<bool>" to be
equal. Following the logic earlier we should probably also allow
ucode=<integer>,builtin. This translates to fallback to builtin if there
are no modules at index <integer>.

Almost - if the builtin one is newer than the separate blob, then
either of the cmdline options you name should still cause the
builtin one to be loaded. IOW you want to honor both options, not
prefer the earlier over a later one.


On the "newest of everything": That's not what I intend to propose. The microcode provided via a scan (or <integer> for that matter) will always override the builtin microcode. The common case would be that the microcode provided via a scan (or <integer>) is newer than the builtin. Yet, an administrator will have the option, if needed, to use an older microcode via a scan (or <integer>) to override a newer builtin microcode.


-- Eslam

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.