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.
> 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.
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.
There is a bit of linkage between EPT/VT-d and NPT/AMD-Vi (in principle
at least) in the form of HAP/IOMMU pagetable sharing, but as it's "just"
an exchange of superpage sizes, iommu-pt pointer and height, I think we
can make an abstraction which doesn't force a vendor match.
>> --- /dev/null
>> +++ b/xen/arch/x86/Kconfig.cpu
>> @@ -0,0 +1,22 @@
>> +menu "Supported processor vendors"
>> + visible if EXPERT
>> +
>> +config AMD
>> + bool "AMD"
>> + default y
>> + help
>> + Detection, tunings and quirks for AMD processors.
>> +
>> + May be turned off in builds targetting other vendors. Otherwise,
>> + must be enabled for Xen to work suitably on AMD processors.
>> +
>> +config INTEL
>> + bool "Intel"
>> + default y
>> + help
>> + Detection, tunings and quirks for Intel processors.
>> +
>> + May be turned off in builds targetting other vendors. Otherwise,
>> + must be enabled for Xen to work suitably on Intel processors.
>> +
>> +endmenu
> Nit: Throughout this hunk there's an inconsistency with indentation
> (hard tabs not used in some places where they ought to be).
Oh yes, that's unintended.
> Also, depending on the verdict on the aspect mentioned at the top,
> "processors" may want replacing by "systems" or "platforms" or some
> such if we mean these to cover more than just the CPUs.
I really don't want to use CPU because that term is overloaded enough
already. Maybe it's ok in the overall menu text, but "plaform/system
vendor" would be the OEMs rather than the processor vendors.
We do have various platform quirks in Xen, but they're almost all DMI or
PCI based, rather than vendor based.
I could be persuaded to use CPU in the menu, and s/processors/platforms/
elsewhere.
~Andrew
