Re: [PATCH v2 2/2] x86/Kconfig: Introduce CONFIG_{AMD,INTEL} and conditionalise ucode

[Jan Beulich <jbeulich@xxxxxxxx>]

On 27.10.2023 21:18, Andrew Cooper wrote:
> On 27/10/2023 2:47 pm, Roger Pau Monné wrote:
>> On Fri, Oct 27, 2023 at 09:12:40AM +0200, Jan Beulich wrote:
>>> On 26.10.2023 22:55, Andrew Cooper wrote:
>>>> We eventually want to be able to build a stripped down Xen for a single
>>>> platform.  Make a start with CONFIG_{AMD,INTEL} (hidden behind EXPERT, but
>>>> available to randconfig), and adjust the microcode logic.
>>>>
>>>> No practical change.
>>>>
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> ---
>>>> CC: Jan Beulich <JBeulich@xxxxxxxx>
>>>> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>>> CC: Wei Liu <wl@xxxxxxx>
>>>> CC: Alejandro Vallejo <alejandro.vallejo@xxxxxxxxx>
>>>> CC: Stefano Stabellini <stefano.stabellini@xxxxxxx>
>>>> CC: Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>
>>>>
>>>> I've intentionally ignored the other vendors for now.  They can be put into
>>>> Kconfig by whomever figures out the actual dependencies between their init
>>>> routines.
>>>>
>>>> v2:
>>>>  * Tweak text
>>> What about the indentation issues mentioned in reply to v1?
>>>
>>> As to using un-amended AMD and INTEL - Roger, what's your view here?
>> I think it would be good to add a suffix, like we do for
>> {AMD,INTEL}_IOMMU options, and reserve the plain AMD and INTEL options
>> as platform/system level options that enable both VENDOR_{CPU,IOMMU}
>> sub options.
>>
>> So yes, {INTEL,AMD}_CPU seems a good option.
> 
> Really?  You do realise that, unlike the IOMMU names, this is going to
> be plastered all over the Makefiles and header files?
> 
> And it breaks the careful attempt not to use the ambigous term when
> describing what the symbol means.

I wonder what you mean here: Describing what the symbol means is all
done in plain text, i.e. independent of the symbol name.

> I'll send out a v2.5 so you can see it in context, but I'm going to say
> straight up - I think this is a mistake.

So in the longer run perhaps we want CONFIG_{AMD,INTEL} _and_
CONFIG_{AMD,INTEL}_CPU? The former mainly to control the defaults of
CONFIG_{AMD,INTEL}_{CPU,IOMMU} (could also be viewed as kind of a
shorthand)?

Jan