Mailing List Archive

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 */

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

Oct 27, 2023, 5:48 AM

Post #3 of 12 (76 views)

On 27/10/2023 8:12 am, Jan Beulich wrote:
> On 26.10.2023 22:55, Andrew Cooper wrote:
>> v2:
>> * Tweak text
> What about the indentation issues mentioned in reply to v1?

Bah, slipped my mind. Sorry.

Fixed up locally.

~Andrew

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

Oct 27, 2023, 6:47 AM

Post #4 of 12 (76 views)

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.

Regards, Roger.

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

Oct 27, 2023, 12:18 PM

Post #5 of 12 (76 views)

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

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

jbeulich at suse

Oct 30, 2023, 1:40 AM

Post #6 of 12 (72 views)

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

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

Oct 30, 2023, 2:07 AM

Post #7 of 12 (72 views)

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.

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

Apr 10, 2024, 8:14 AM

Post #8 of 12 (9 views)

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.

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

Apr 10, 2024, 9:21 AM

Post #9 of 12 (9 views)

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

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

Apr 10, 2024, 9:34 AM

Post #10 of 12 (9 views)

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.

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

Apr 10, 2024, 10:49 AM

Post #11 of 12 (9 views)

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

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

sstabellini at kernel

Apr 10, 2024, 11:18 AM

Post #12 of 12 (9 views)