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

[Jan Beulich <jbeulich@xxxxxxxx>]

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

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