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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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