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

Re: [Xen-devel] [PATCH v2 1/4] x86/microcode: Improve documentation and parsing for ucode=



On 21.01.20 10:27, Jan Beulich wrote:
On 21.01.2020 00:50, Eslam Elnikety wrote:
On 20.01.20 09:42, Jan Beulich wrote:
On 17.01.2020 20:06, Eslam Elnikety wrote:
On 20.12.19 10:53, Jan Beulich wrote:
On 19.12.2019 22:08, Eslam Elnikety wrote:
On 18.12.19 12:49, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
Decouple the microcode referencing mechanism when using GRUB to that
when using EFI. This allows us to avoid the "unspecified effect" of
using `<integer> | scan` along xen.efi.

I guess "unspecified effect" in the doc was pretty pointless - such
options have been ignored before; in fact ...

With that, Xen can explicitly
ignore those named options when using EFI.

... I don't see things becoming any more explicit (not even parsing
the options was quite explicit to me).


I agree that those options have been ignored so far in the case of EFI.
The documentation contradicts that however. The documentation:
* says <integer> has unspecified effect.
* does not mention anything about scan being ignored.

With this patch, it is explicit in code and in documentation that both
options are ignored in case of EFI.

But isn't it rather that ucode=scan could (and hence perhaps should)
also have its value on EFI?


I do not see "ucode=scan" applicable in anyway in the case of EFI. In
EFI, there are not "modules" to scan through, but rather the efi config
points exactly to the microcode blob.

What would be wrong with the EFI code to also inspect whatever has been
specified with ramdisk= if there was no ucode= ?

I see, interesting. This sounds like a legitimate use case indeed. I
wonder, would I be breaking anything if I simply allow the existing code
that iterates over modules to kick in when ucode=scan irrespective of
EFI or legacy boot?

I don't think so, no, but it would need double checking (and
mentioning in the description and/or documentation).

Also, it seems to me that the ucode= specified by
efi.cfg would take precedence over the ucode=scan. Do not you think?

I guess we need to settle on what we want to take precedence and
then make sure code also behaves this way. But yes, I think ucode=
from the .cfg should supersede ucode=scan on the command line. A
possibly useful adjustment to this might be to distinguish whether
the ucode=scan was in a specific .cfg section while the ucode= was
in [global] (i.e. sort of a default), in which case maybe the
ucode=scan should win. Thoughts?

Jan


I think any ucode= in the EFI .cfg ought to supersede the ucode=scan. The semantics are simpler in this case, rather than having to worry about where exactly the ucode= was specified in the EFI .cfg. With that, an administrator would default to using ucode=scan on the commandline to load the ramdisk microcode, and a ucode= in .cfg would be an explicit signal to use different 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®.