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

From: Jan Beulich <jbeulich@suse.com>
To: Eslam Elnikety <elnikety@amazon.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Paul Durrant <pdurrant@amazon.co.uk>,
	xen-devel@lists.xenproject.org,
	David Woodhouse <dwmw@amazon.co.uk>
Subject: Re: [Xen-devel] [PATCH v2 1/4] x86/microcode: Improve documentation and parsing for ucode=
Date: Tue, 21 Jan 2020 10:27:47 +0100	[thread overview]
Message-ID: <f3f0f684-2520-e7de-870a-7d7be40f66b2@suse.com> (raw)
In-Reply-To: <d93d5931-6b59-649b-c989-9263c3c9a913@amazon.com>

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel