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

[Eslam Elnikety <elnikety@xxxxxxxxxx>]

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