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

[Eslam Elnikety <elnikety@xxxxxxxxxx>]

On 21.01.20 21:51, Eslam Elnikety wrote:
> 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
So that happens to be the existing behaviour already :)

I was under the impression that ucode=scan was simply ignored under EFI. 
That's not the case. It is only ignored if ucode=<filename> is specified 
in the EFI config. In other words, what we had just discussed above is 
already the case. This clearly needs spelling out in the documentation, 
which is the first patch in the "x86/microcode: Improve documentation 
and code" series I have sent just now.
Cheers,
Eslam






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