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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Jan 21, 2020 at 10:27:47AM +0100, 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).

Originally I wanted to have 'ucode=scan' be the default choice. That
would have been the easiest choice.
 

> 
> > 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

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