On 26/10/2023 12:35 pm, Jan Beulich wrote:
> 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>.
Odd possibly, but not something to worry about.
It's mostly because of asymmetric marketing because while VTD is fine
and recognisable, AMD-Vi has AMD's name in it even for the non-AMD vendors.
Anyone liable to even notice in the first place will probably know
enough to understand why it's like that.
Furthermore, ...
> Whereas the lack of a
> dependency on <vendor>_CPU would be quite natural, imo.
... this doesn't really work either as IOMMUs are non-really-optional
uncore components these days.
Names are just that - names. They can be changed if needs be, and it's
the help text which matters to clarify the intent.
~Andrew
