xen/arch/x86/Kconfig | 12 ++++++++++++ xen/arch/x86/cpu/microcode/Makefile | 4 ++-- xen/arch/x86/cpu/microcode/core.c | 5 ++++- 3 files changed, 18 insertions(+), 3 deletions(-)
Introduce configuration variables to make it possible to selectively turn
on/off CPU microcode management code in the build for AMD and Intel CPUs.
This is to allow build configuration for a specific CPU, not compile and
load what will not be used anyway.
Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
---
xen/arch/x86/Kconfig | 12 ++++++++++++
xen/arch/x86/cpu/microcode/Makefile | 4 ++--
xen/arch/x86/cpu/microcode/core.c | 5 ++++-
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index d6f3128588..1ee5ae793d 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -350,6 +350,18 @@ config REQUIRE_NX
was unavailable. However, if enabled, Xen will no longer boot on
any CPU which is lacking NX support.
+config MICROCODE_INTEL
+ bool "Build with Intel CPU ucode support" if EXPERT
+ default y
+ help
+ Support microcode management for Intel processors. If unsure, say Y.
+
+config MICROCODE_AMD
+ bool "Build with AMD CPU ucode support" if EXPERT
+ default y
+ help
+ Support microcode management for AMD K10 family of processors
+ and later. If unsure, say Y.
endmenu
source "common/Kconfig"
diff --git a/xen/arch/x86/cpu/microcode/Makefile b/xen/arch/x86/cpu/microcode/Makefile
index aae235245b..abd0afe8c5 100644
--- a/xen/arch/x86/cpu/microcode/Makefile
+++ b/xen/arch/x86/cpu/microcode/Makefile
@@ -1,3 +1,3 @@
-obj-y += amd.o
obj-y += core.o
-obj-y += intel.o
+obj-$(CONFIG_MICROCODE_AMD) += amd.o
+obj-$(CONFIG_MICROCODE_INTEL) += intel.o
diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 1c9f66ea8a..b7c108f68b 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -865,6 +865,7 @@ int __init early_microcode_init(unsigned long *module_map,
switch ( c->x86_vendor )
{
+#ifdef CONFIG_MICROCODE_AMD
case X86_VENDOR_AMD:
if ( c->x86 >= 0x10 )
{
@@ -872,11 +873,13 @@ int __init early_microcode_init(unsigned long *module_map,
can_load = true;
}
break;
-
+#endif
+#ifdef CONFIG_MICROCODE_INTEL
case X86_VENDOR_INTEL:
ucode_ops = intel_ucode_ops;
can_load = intel_can_load_microcode();
break;
+#endif
}
if ( !ucode_ops.apply_microcode )
--
2.25.1On 05/04/2024 11:30 am, Sergiy Kibrik wrote: > Introduce configuration variables to make it possible to selectively turn > on/off CPU microcode management code in the build for AMD and Intel CPUs. > > This is to allow build configuration for a specific CPU, not compile and > load what will not be used anyway. > > Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> Hmm... Stefano didn't check up with me first. https://lore.kernel.org/xen-devel/20231027191926.3283871-1-andrew.cooper3@citrix.com/ I've already got a series out for this, although its blocked on naming and IMO, particularly unhelpful replies. I've not had time to apply the community-resolution vote on naming issues. (Also, you should be CC-ing Roger on x86 patches). For microcode loading specifically, there's no situation even for safety certification where it's reasonable to remove this functionality. Therefore it wants tying to generic Intel / AMD only, and not a ucode-loading specific option. ~Andrew
05.04.24 13:57, Andrew Cooper: > On 05/04/2024 11:30 am, Sergiy Kibrik wrote: >> Introduce configuration variables to make it possible to selectively turn >> on/off CPU microcode management code in the build for AMD and Intel CPUs. >> >> This is to allow build configuration for a specific CPU, not compile and >> load what will not be used anyway. >> >> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> > > Hmm... Stefano didn't check up with me first. > > _https://lore.kernel.org/xen-devel/20231027191926.3283871-1-andrew.cooper3@citrix.com/ > > I've already got a series out for this, although its blocked on naming > and IMO, particularly unhelpful replies. I've not had time to apply the > community-resolution vote on naming issues. (Also, you should be CC-ing > Roger on x86 patches). + Stefano & Roger should we revisit this series then? -Sergiy
On Tue, 9 Apr 2024, Sergiy Kibrik wrote:
> 05.04.24 13:57, Andrew Cooper:
> > On 05/04/2024 11:30 am, Sergiy Kibrik wrote:
> > > Introduce configuration variables to make it possible to selectively turn
> > > on/off CPU microcode management code in the build for AMD and Intel CPUs.
> > >
> > > This is to allow build configuration for a specific CPU, not compile and
> > > load what will not be used anyway.
> > >
> > > Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
> >
> > Hmm... Stefano didn't check up with me first.
> >
> > _https://lore.kernel.org/xen-devel/20231027191926.3283871-1-andrew.cooper3@citrix.com/
> >
> > I've already got a series out for this, although its blocked on naming
> > and IMO, particularly unhelpful replies. I've not had time to apply the
> > community-resolution vote on naming issues. (Also, you should be CC-ing
> > Roger on x86 patches).
>
> + Stefano & Roger
>
> should we revisit this series then?
Yes, I replied. I think there are three naming options:
Option-1)
CONFIG_{AMD,INTEL}
nothing else
Option-2)
CONFIG_{AMD,INTEL}_IOMMU
CONFIG_{AMD,INTEL} selects CONFIG_{AMD,INTEL}_IOMMU
Option-3)
CONFIG_{AMD,INTEL}_IOMMU
CONFIG_{AMD,INTEL}_CPU
CONFIG_{AMD,INTEL} selects both CPU and IOMMU options
My preference is Option-1 (best), Option-3, Option-2 (worse)
I am fine with anything but please let move this forward.
On 09.04.2024 23:49, Stefano Stabellini wrote:
> On Tue, 9 Apr 2024, Sergiy Kibrik wrote:
>> 05.04.24 13:57, Andrew Cooper:
>>> On 05/04/2024 11:30 am, Sergiy Kibrik wrote:
>>>> Introduce configuration variables to make it possible to selectively turn
>>>> on/off CPU microcode management code in the build for AMD and Intel CPUs.
>>>>
>>>> This is to allow build configuration for a specific CPU, not compile and
>>>> load what will not be used anyway.
>>>>
>>>> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
>>>
>>> Hmm... Stefano didn't check up with me first.
>>>
>>> _https://lore.kernel.org/xen-devel/20231027191926.3283871-1-andrew.cooper3@citrix.com/
>>>
>>> I've already got a series out for this, although its blocked on naming
>>> and IMO, particularly unhelpful replies. I've not had time to apply the
>>> community-resolution vote on naming issues. (Also, you should be CC-ing
>>> Roger on x86 patches).
I can't remain silent here. Roger has now changed his mind, so formally
things are correct. Yet judging from the earlier example where Roger
was agreeing with you, shouldn't it have been this time the other way
around: A majority was of different opinion than you, and you should
have accepted that? Instead you've waited for a time when I was away,
got Stefano to agree and Roger to change his mind, and once again you
got what you want. It feels increasingly like not everyone among the
REST maintainers and not everyone among the x86 ones are equal.
Jan
>> + Stefano & Roger
>>
>> should we revisit this series then?
>
> Yes, I replied. I think there are three naming options:
>
> Option-1)
> CONFIG_{AMD,INTEL}
> nothing else
>
> Option-2)
> CONFIG_{AMD,INTEL}_IOMMU
> CONFIG_{AMD,INTEL} selects CONFIG_{AMD,INTEL}_IOMMU
>
> Option-3)
> CONFIG_{AMD,INTEL}_IOMMU
> CONFIG_{AMD,INTEL}_CPU
> CONFIG_{AMD,INTEL} selects both CPU and IOMMU options
>
>
> My preference is Option-1 (best), Option-3, Option-2 (worse)
>
> I am fine with anything but please let move this forward.
© 2016 - 2024 Red Hat, Inc.