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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.10.2023 13:10, Andrew Cooper wrote:
> On 26/10/2023 8:55 am, Jan Beulich wrote:
>> On 25.10.2023 20:06, 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.
>> Linux uses different names for the Kconfig symbols. While I'm unconvinced
>> of the SUP part, I wonder whether we wouldn't better use CPU in the names.
> 
> I don't see what that gets us, other than a longer name.

Just to mention the (I think) obvious - on the IOMMU side we already have
AMD_IOMMU and INTEL_IOMMU. It would be odd to have just AMD and INTEL here,
yet then ...

>> One immediate question here is how the IOMMU interaction is intended to
>> end up: Do we want to permit either vendor's CPUs with the other vendor's
>> IOMMUs to be usable?
> 
> From a randconfig point of view, yes.  These options are only targetting
> a specific platform, and we can absolutely make that the end user's
> responsibility to describe their platform correctly.

... <vendor>_IOMMU not depending on <vendor>. Whereas the lack of a
dependency on <vendor>_CPU would be quite natural, imo.

> The more interesting question is perhaps VT-x and SVM, given that VIA
> have shipped VT-x and Hygon have shipped SVM and AMD-Vi.
> 
> I do specifically want to to integrate the HVM setup better with CPU
> init - KVM dropped an enormous amount of complexity by doing this - but
> I expect we'll end up with VTX and SVM options rather than using
> INTEL/AMD for this.

I'd certainly prefer us using VTX/SVM (and those then having dependencies
on the main || niche vendors), with the caveat that SVM also has had a
meaning for Intel for quite some time, iirc.

Jan