| Message ID | 20231026205539.3261811-3-andrew.cooper3@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: ucode and CPU Kconfig | expand |
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@citrix.com> > --- > CC: Jan Beulich <JBeulich@suse.com> > CC: Roger Pau Monné <roger.pau@citrix.com> > CC: Wei Liu <wl@xen.org> > CC: Alejandro Vallejo <alejandro.vallejo@cloud.com> > CC: Stefano Stabellini <stefano.stabellini@amd.com> > CC: Xenia Ragiadakou <xenia.ragiadakou@amd.com> > > 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'm not outright opposed, but to me it feels misleading to omit CPU from those Kconfig symbols. Jan > --- > xen/arch/x86/Kconfig | 2 ++ > xen/arch/x86/Kconfig.cpu | 22 ++++++++++++++++++++++ > xen/arch/x86/cpu/microcode/Makefile | 4 ++-- > xen/arch/x86/cpu/microcode/private.h | 9 +++++++++ > 4 files changed, 35 insertions(+), 2 deletions(-) > create mode 100644 xen/arch/x86/Kconfig.cpu > > diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig > index eac77573bd75..d9eacdd7e0fa 100644 > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -49,6 +49,8 @@ config HAS_CC_CET_IBT > > menu "Architecture Features" > > +source "arch/x86/Kconfig.cpu" > + > source "arch/Kconfig" > > config PV > diff --git a/xen/arch/x86/Kconfig.cpu b/xen/arch/x86/Kconfig.cpu > new file mode 100644 > index 000000000000..3c5d88fdfd16 > --- /dev/null > +++ b/xen/arch/x86/Kconfig.cpu > @@ -0,0 +1,22 @@ > +menu "Supported CPU vendors" > + visible if EXPERT > + > +config AMD > + bool "AMD" > + default y > + help > + Detection, tunings and quirks for AMD platforms. > + > + May be turned off in builds targetting other vendors. Otherwise, > + must be enabled for Xen to work suitably on AMD platforms. > + > +config INTEL > + bool "Intel" > + default y > + help > + Detection, tunings and quirks for Intel platforms. > + > + May be turned off in builds targetting other vendors. Otherwise, > + must be enabled for Xen to work suitably on Intel platforms. > + > +endmenu > diff --git a/xen/arch/x86/cpu/microcode/Makefile b/xen/arch/x86/cpu/microcode/Makefile > index aae235245b06..30d600544f45 100644 > --- a/xen/arch/x86/cpu/microcode/Makefile > +++ b/xen/arch/x86/cpu/microcode/Makefile > @@ -1,3 +1,3 @@ > -obj-y += amd.o > +obj-$(CONFIG_AMD) += amd.o > obj-y += core.o > -obj-y += intel.o > +obj-$(CONFIG_INTEL) += intel.o > diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h > index b58611e908aa..da556fe5060a 100644 > --- a/xen/arch/x86/cpu/microcode/private.h > +++ b/xen/arch/x86/cpu/microcode/private.h > @@ -70,7 +70,16 @@ struct microcode_ops { > * support available) and (not) ops->apply_microcode (i.e. read only). > * Otherwise, all hooks must be filled in. > */ > +#ifdef CONFIG_AMD > void ucode_probe_amd(struct microcode_ops *ops); > +#else > +static inline void ucode_probe_amd(struct microcode_ops *ops) {} > +#endif > + > +#ifdef CONFIG_INTEL > void ucode_probe_intel(struct microcode_ops *ops); > +#else > +static inline void ucode_probe_intel(struct microcode_ops *ops) {} > +#endif > > #endif /* ASM_X86_MICROCODE_PRIVATE_H */
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@citrix.com> >>> --- >>> CC: Jan Beulich <JBeulich@suse.com> >>> CC: Roger Pau Monné <roger.pau@citrix.com> >>> CC: Wei Liu <wl@xen.org> >>> CC: Alejandro Vallejo <alejandro.vallejo@cloud.com> >>> CC: Stefano Stabellini <stefano.stabellini@amd.com> >>> CC: Xenia Ragiadakou <xenia.ragiadakou@amd.com> >>> >>> 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'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. ~Andrew
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@citrix.com> >>>> --- >>>> CC: Jan Beulich <JBeulich@suse.com> >>>> CC: Roger Pau Monné <roger.pau@citrix.com> >>>> CC: Wei Liu <wl@xen.org> >>>> CC: Alejandro Vallejo <alejandro.vallejo@cloud.com> >>>> CC: Stefano Stabellini <stefano.stabellini@amd.com> >>>> CC: Xenia Ragiadakou <xenia.ragiadakou@amd.com> >>>> >>>> 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
On Fri, Oct 27, 2023 at 08:18:18PM +0100, 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@citrix.com> > >>> --- > >>> CC: Jan Beulich <JBeulich@suse.com> > >>> CC: Roger Pau Monné <roger.pau@citrix.com> > >>> CC: Wei Liu <wl@xen.org> > >>> CC: Alejandro Vallejo <alejandro.vallejo@cloud.com> > >>> CC: Stefano Stabellini <stefano.stabellini@amd.com> > >>> CC: Xenia Ragiadakou <xenia.ragiadakou@amd.com> > >>> > >>> 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? What's it different from using INTEL_CPU than just plain INTEL? It's still 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'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. My point is that we might want to reserve the top level names (iow: CONFIG_INTEL, CONFIG_AMD, CONFIG_{VENDOR}) for system wide options that enable both the CPU and the IOMMU code needed for the selected vendor. I'm happy to use a name different than {INTEL,AMD}_CPU for the vendor CPU/platform code. Alternatively, I would be fine to use CONFIG_{INTEL,AMD} as long as the existing CONFIG_{AMD,INTEL}_IOMMU Kconfig options are made dependent on the newly introduced CONFIG_{INTEL,AMD} options, so when disabling CONFIG_AMD CONFIG_AMD_IOMMU also gets disabled. Maybe that's already the intention of the suggested CONFIG_{AMD,INTEL} and I'm missing the point. Thanks, Roger.
On Thu, Oct 26, 2023 at 09:55:39PM +0100, 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@citrix.com> > --- > CC: Jan Beulich <JBeulich@suse.com> > CC: Roger Pau Monné <roger.pau@citrix.com> > CC: Wei Liu <wl@xen.org> > CC: Alejandro Vallejo <alejandro.vallejo@cloud.com> > CC: Stefano Stabellini <stefano.stabellini@amd.com> > CC: Xenia Ragiadakou <xenia.ragiadakou@amd.com> > > 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 > --- > xen/arch/x86/Kconfig | 2 ++ > xen/arch/x86/Kconfig.cpu | 22 ++++++++++++++++++++++ > xen/arch/x86/cpu/microcode/Makefile | 4 ++-- > xen/arch/x86/cpu/microcode/private.h | 9 +++++++++ > 4 files changed, 35 insertions(+), 2 deletions(-) > create mode 100644 xen/arch/x86/Kconfig.cpu > > diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig > index eac77573bd75..d9eacdd7e0fa 100644 > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -49,6 +49,8 @@ config HAS_CC_CET_IBT > > menu "Architecture Features" > > +source "arch/x86/Kconfig.cpu" Since we are not targeting at the CPU only, would this be better named as Kconfig.vendor? Or Kconfig.platform? (I'm OK if you prefer to leave as .cpu, just suggesting more neutral names. > + > source "arch/Kconfig" > > config PV > diff --git a/xen/arch/x86/Kconfig.cpu b/xen/arch/x86/Kconfig.cpu > new file mode 100644 > index 000000000000..3c5d88fdfd16 > --- /dev/null > +++ b/xen/arch/x86/Kconfig.cpu > @@ -0,0 +1,22 @@ > +menu "Supported CPU vendors" > + visible if EXPERT > + > +config AMD > + bool "AMD" > + default y > + help > + Detection, tunings and quirks for AMD platforms. > + > + May be turned off in builds targetting other vendors. Otherwise, > + must be enabled for Xen to work suitably on AMD platforms. > + > +config INTEL > + bool "Intel" > + default y > + help > + Detection, tunings and quirks for Intel platforms. > + > + May be turned off in builds targetting other vendors. Otherwise, > + must be enabled for Xen to work suitably on Intel platforms. There seems to be a weird mix between hard tabs and spaces above. Naming is OK for me. > + > +endmenu > diff --git a/xen/arch/x86/cpu/microcode/Makefile b/xen/arch/x86/cpu/microcode/Makefile > index aae235245b06..30d600544f45 100644 > --- a/xen/arch/x86/cpu/microcode/Makefile > +++ b/xen/arch/x86/cpu/microcode/Makefile > @@ -1,3 +1,3 @@ > -obj-y += amd.o > +obj-$(CONFIG_AMD) += amd.o > obj-y += core.o > -obj-y += intel.o > +obj-$(CONFIG_INTEL) += intel.o > diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h > index b58611e908aa..da556fe5060a 100644 > --- a/xen/arch/x86/cpu/microcode/private.h > +++ b/xen/arch/x86/cpu/microcode/private.h > @@ -70,7 +70,16 @@ struct microcode_ops { > * support available) and (not) ops->apply_microcode (i.e. read only). > * Otherwise, all hooks must be filled in. > */ > +#ifdef CONFIG_AMD > void ucode_probe_amd(struct microcode_ops *ops); > +#else > +static inline void ucode_probe_amd(struct microcode_ops *ops) {} > +#endif > + > +#ifdef CONFIG_INTEL > void ucode_probe_intel(struct microcode_ops *ops); > +#else > +static inline void ucode_probe_intel(struct microcode_ops *ops) {} This is stale now, and will need some updating to match what's in private.h. Thanks, Roger.
On 10/04/2024 4:14 pm, Roger Pau Monné wrote: > On Thu, Oct 26, 2023 at 09:55:39PM +0100, 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@citrix.com> >> --- >> CC: Jan Beulich <JBeulich@suse.com> >> CC: Roger Pau Monné <roger.pau@citrix.com> >> CC: Wei Liu <wl@xen.org> >> CC: Alejandro Vallejo <alejandro.vallejo@cloud.com> >> CC: Stefano Stabellini <stefano.stabellini@amd.com> >> CC: Xenia Ragiadakou <xenia.ragiadakou@amd.com> >> >> 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 >> --- >> xen/arch/x86/Kconfig | 2 ++ >> xen/arch/x86/Kconfig.cpu | 22 ++++++++++++++++++++++ >> xen/arch/x86/cpu/microcode/Makefile | 4 ++-- >> xen/arch/x86/cpu/microcode/private.h | 9 +++++++++ >> 4 files changed, 35 insertions(+), 2 deletions(-) >> create mode 100644 xen/arch/x86/Kconfig.cpu >> >> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig >> index eac77573bd75..d9eacdd7e0fa 100644 >> --- a/xen/arch/x86/Kconfig >> +++ b/xen/arch/x86/Kconfig >> @@ -49,6 +49,8 @@ config HAS_CC_CET_IBT >> >> menu "Architecture Features" >> >> +source "arch/x86/Kconfig.cpu" > Since we are not targeting at the CPU only, would this be better named > as Kconfig.vendor? Or Kconfig.platform? (I'm OK if you prefer to > leave as .cpu, just suggesting more neutral names. Well - its based on ... > >> + >> source "arch/Kconfig" >> >> config PV >> diff --git a/xen/arch/x86/Kconfig.cpu b/xen/arch/x86/Kconfig.cpu >> new file mode 100644 >> index 000000000000..3c5d88fdfd16 >> --- /dev/null >> +++ b/xen/arch/x86/Kconfig.cpu >> @@ -0,0 +1,22 @@ >> +menu "Supported CPU vendors" >> + visible if EXPERT ... this, and I think "cpu" is the thing that is going to be most meaningful to people. (Also because this is what Linux calls the file.) Technically platform would be the right term, but "CPU vendors" is what you call Intel / AMD / etc in the x86 world. >> + >> +config AMD >> + bool "AMD" >> + default y >> + help >> + Detection, tunings and quirks for AMD platforms. >> + >> + May be turned off in builds targetting other vendors. Otherwise, >> + must be enabled for Xen to work suitably on AMD platforms. >> + >> +config INTEL >> + bool "Intel" >> + default y >> + help >> + Detection, tunings and quirks for Intel platforms. >> + >> + May be turned off in builds targetting other vendors. Otherwise, >> + must be enabled for Xen to work suitably on Intel platforms. > There seems to be a weird mix between hard tabs and spaces above. > Naming is OK for me. Yeah. I already fixed those locally. > >> + >> +endmenu >> diff --git a/xen/arch/x86/cpu/microcode/Makefile b/xen/arch/x86/cpu/microcode/Makefile >> index aae235245b06..30d600544f45 100644 >> --- a/xen/arch/x86/cpu/microcode/Makefile >> +++ b/xen/arch/x86/cpu/microcode/Makefile >> @@ -1,3 +1,3 @@ >> -obj-y += amd.o >> +obj-$(CONFIG_AMD) += amd.o >> obj-y += core.o >> -obj-y += intel.o >> +obj-$(CONFIG_INTEL) += intel.o >> diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h >> index b58611e908aa..da556fe5060a 100644 >> --- a/xen/arch/x86/cpu/microcode/private.h >> +++ b/xen/arch/x86/cpu/microcode/private.h >> @@ -70,7 +70,16 @@ struct microcode_ops { >> * support available) and (not) ops->apply_microcode (i.e. read only). >> * Otherwise, all hooks must be filled in. >> */ >> +#ifdef CONFIG_AMD >> void ucode_probe_amd(struct microcode_ops *ops); >> +#else >> +static inline void ucode_probe_amd(struct microcode_ops *ops) {} >> +#endif >> + >> +#ifdef CONFIG_INTEL >> void ucode_probe_intel(struct microcode_ops *ops); >> +#else >> +static inline void ucode_probe_intel(struct microcode_ops *ops) {} > This is stale now, and will need some updating to match what's in > private.h. There's nothing state I can see. Patch 1 does significantly edit this vs what's currently in staging. ~Andrew
On Wed, Apr 10, 2024 at 05:21:37PM +0100, Andrew Cooper wrote: > On 10/04/2024 4:14 pm, Roger Pau Monné wrote: > > On Thu, Oct 26, 2023 at 09:55:39PM +0100, Andrew Cooper wrote: > >> + > >> +config AMD > >> + bool "AMD" > >> + default y > >> + help > >> + Detection, tunings and quirks for AMD platforms. > >> + > >> + May be turned off in builds targetting other vendors. Otherwise, > >> + must be enabled for Xen to work suitably on AMD platforms. > >> + > >> +config INTEL > >> + bool "Intel" > >> + default y > >> + help > >> + Detection, tunings and quirks for Intel platforms. > >> + > >> + May be turned off in builds targetting other vendors. Otherwise, > >> + must be enabled for Xen to work suitably on Intel platforms. > > There seems to be a weird mix between hard tabs and spaces above. > > Naming is OK for me. > > Yeah. I already fixed those locally. With that fixed: Acked-by: Roger Pau Monné <roger.pau@citrix.com> > >> + > >> +endmenu > >> diff --git a/xen/arch/x86/cpu/microcode/Makefile b/xen/arch/x86/cpu/microcode/Makefile > >> index aae235245b06..30d600544f45 100644 > >> --- a/xen/arch/x86/cpu/microcode/Makefile > >> +++ b/xen/arch/x86/cpu/microcode/Makefile > >> @@ -1,3 +1,3 @@ > >> -obj-y += amd.o > >> +obj-$(CONFIG_AMD) += amd.o > >> obj-y += core.o > >> -obj-y += intel.o > >> +obj-$(CONFIG_INTEL) += intel.o > >> diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h > >> index b58611e908aa..da556fe5060a 100644 > >> --- a/xen/arch/x86/cpu/microcode/private.h > >> +++ b/xen/arch/x86/cpu/microcode/private.h > >> @@ -70,7 +70,16 @@ struct microcode_ops { > >> * support available) and (not) ops->apply_microcode (i.e. read only). > >> * Otherwise, all hooks must be filled in. > >> */ > >> +#ifdef CONFIG_AMD > >> void ucode_probe_amd(struct microcode_ops *ops); > >> +#else > >> +static inline void ucode_probe_amd(struct microcode_ops *ops) {} > >> +#endif > >> + > >> +#ifdef CONFIG_INTEL > >> void ucode_probe_intel(struct microcode_ops *ops); > >> +#else > >> +static inline void ucode_probe_intel(struct microcode_ops *ops) {} > > This is stale now, and will need some updating to match what's in > > private.h. > > There's nothing state I can see. > > Patch 1 does significantly edit this vs what's currently in staging. Oh, sorry, I'm missed patch 1 then. Thanks, Roger.
On 10/04/2024 5:34 pm, Roger Pau Monné wrote: > On Wed, Apr 10, 2024 at 05:21:37PM +0100, Andrew Cooper wrote: >> On 10/04/2024 4:14 pm, Roger Pau Monné wrote: >>> On Thu, Oct 26, 2023 at 09:55:39PM +0100, Andrew Cooper wrote: >>>> + >>>> +config AMD >>>> + bool "AMD" After double checking what {menu,old}config looks like, I've extended these prompts "Support $X CPU" so they make more sense in the context they're asked in. >>>> + default y >>>> + help >>>> + Detection, tunings and quirks for AMD platforms. >>>> + >>>> + May be turned off in builds targetting other vendors. Otherwise, >>>> + must be enabled for Xen to work suitably on AMD platforms. >>>> + >>>> +config INTEL >>>> + bool "Intel" >>>> + default y >>>> + help >>>> + Detection, tunings and quirks for Intel platforms. >>>> + >>>> + May be turned off in builds targetting other vendors. Otherwise, >>>> + must be enabled for Xen to work suitably on Intel platforms. >>> There seems to be a weird mix between hard tabs and spaces above. >>> Naming is OK for me. >> Yeah. I already fixed those locally. > With that fixed: > > Acked-by: Roger Pau Monné <roger.pau@citrix.com> Thanks. We can always tweak later if necessary. ~Andrew
On Wed, 10 Apr 2024, Roger Pau Monné wrote: > On Wed, Apr 10, 2024 at 05:21:37PM +0100, Andrew Cooper wrote: > > On 10/04/2024 4:14 pm, Roger Pau Monné wrote: > > > On Thu, Oct 26, 2023 at 09:55:39PM +0100, Andrew Cooper wrote: > > >> + > > >> +config AMD > > >> + bool "AMD" > > >> + default y > > >> + help > > >> + Detection, tunings and quirks for AMD platforms. > > >> + > > >> + May be turned off in builds targetting other vendors. Otherwise, > > >> + must be enabled for Xen to work suitably on AMD platforms. > > >> + > > >> +config INTEL > > >> + bool "Intel" > > >> + default y > > >> + help > > >> + Detection, tunings and quirks for Intel platforms. > > >> + > > >> + May be turned off in builds targetting other vendors. Otherwise, > > >> + must be enabled for Xen to work suitably on Intel platforms. > > > There seems to be a weird mix between hard tabs and spaces above. > > > Naming is OK for me. > > > > Yeah. I already fixed those locally. > > With that fixed: > > Acked-by: Roger Pau Monné <roger.pau@citrix.com> This is fine for me too Acked-by: Stefano Stabellini <sstabellini@kernel.org>
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index eac77573bd75..d9eacdd7e0fa 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -49,6 +49,8 @@ config HAS_CC_CET_IBT menu "Architecture Features" +source "arch/x86/Kconfig.cpu" + source "arch/Kconfig" config PV diff --git a/xen/arch/x86/Kconfig.cpu b/xen/arch/x86/Kconfig.cpu new file mode 100644 index 000000000000..3c5d88fdfd16 --- /dev/null +++ b/xen/arch/x86/Kconfig.cpu @@ -0,0 +1,22 @@ +menu "Supported CPU vendors" + visible if EXPERT + +config AMD + bool "AMD" + default y + help + Detection, tunings and quirks for AMD platforms. + + May be turned off in builds targetting other vendors. Otherwise, + must be enabled for Xen to work suitably on AMD platforms. + +config INTEL + bool "Intel" + default y + help + Detection, tunings and quirks for Intel platforms. + + May be turned off in builds targetting other vendors. Otherwise, + must be enabled for Xen to work suitably on Intel platforms. + +endmenu diff --git a/xen/arch/x86/cpu/microcode/Makefile b/xen/arch/x86/cpu/microcode/Makefile index aae235245b06..30d600544f45 100644 --- a/xen/arch/x86/cpu/microcode/Makefile +++ b/xen/arch/x86/cpu/microcode/Makefile @@ -1,3 +1,3 @@ -obj-y += amd.o +obj-$(CONFIG_AMD) += amd.o obj-y += core.o -obj-y += intel.o +obj-$(CONFIG_INTEL) += intel.o diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h index b58611e908aa..da556fe5060a 100644 --- a/xen/arch/x86/cpu/microcode/private.h +++ b/xen/arch/x86/cpu/microcode/private.h @@ -70,7 +70,16 @@ struct microcode_ops { * support available) and (not) ops->apply_microcode (i.e. read only). * Otherwise, all hooks must be filled in. */ +#ifdef CONFIG_AMD void ucode_probe_amd(struct microcode_ops *ops); +#else +static inline void ucode_probe_amd(struct microcode_ops *ops) {} +#endif + +#ifdef CONFIG_INTEL void ucode_probe_intel(struct microcode_ops *ops); +#else +static inline void ucode_probe_intel(struct microcode_ops *ops) {} +#endif #endif /* ASM_X86_MICROCODE_PRIVATE_H */
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@citrix.com> --- CC: Jan Beulich <JBeulich@suse.com> CC: Roger Pau Monné <roger.pau@citrix.com> CC: Wei Liu <wl@xen.org> CC: Alejandro Vallejo <alejandro.vallejo@cloud.com> CC: Stefano Stabellini <stefano.stabellini@amd.com> CC: Xenia Ragiadakou <xenia.ragiadakou@amd.com> 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 --- xen/arch/x86/Kconfig | 2 ++ xen/arch/x86/Kconfig.cpu | 22 ++++++++++++++++++++++ xen/arch/x86/cpu/microcode/Makefile | 4 ++-- xen/arch/x86/cpu/microcode/private.h | 9 +++++++++ 4 files changed, 35 insertions(+), 2 deletions(-) create mode 100644 xen/arch/x86/Kconfig.cpu