For the purposes of certification, we want as little code as possible to
be unconditionally compiled in. Make CPU hotplug and SMT operations
configurable to ease the process. This will also help with introducing
CPU hotplug on Arm, where it needs to be configurable.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
---
v6->v7:
* new patch
---
xen/arch/x86/platform_hypercall.c | 12 ++++++++++++
xen/arch/x86/smp.c | 3 +++
xen/arch/x86/sysctl.c | 11 +++++++++++
xen/common/Kconfig | 8 ++++++++
4 files changed, 34 insertions(+)
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index cd4f0ae5e5..e745151790 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -735,6 +735,12 @@ ret_t do_platform_op(
{
int cpu = op->u.cpu_ol.cpuid;
+ if ( !IS_ENABLED(CONFIG_CPU_HOTPLUG) )
+ {
+ ret = -EOPNOTSUPP;
+ break;
+ }
+
ret = xsm_resource_plug_core(XSM_HOOK);
if ( ret )
break;
@@ -761,6 +767,12 @@ ret_t do_platform_op(
{
int cpu = op->u.cpu_ol.cpuid;
+ if ( !IS_ENABLED(CONFIG_CPU_HOTPLUG) )
+ {
+ ret = -EOPNOTSUPP;
+ break;
+ }
+
ret = xsm_resource_unplug_core(XSM_HOOK);
if ( ret )
break;
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 7936294f5f..a49505fb57 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -418,6 +418,7 @@ void cf_check call_function_interrupt(void)
smp_call_function_interrupt();
}
+#ifdef CONFIG_CPU_HOTPLUG
long cf_check cpu_up_helper(void *data)
{
unsigned int cpu = (unsigned long)data;
@@ -445,8 +446,10 @@ long cf_check cpu_down_helper(void *data)
{
int cpu = (unsigned long)data;
int ret = cpu_down(cpu);
+
/* Have one more go on EBUSY. */
if ( ret == -EBUSY )
ret = cpu_down(cpu);
return ret;
}
+#endif
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 1b04947516..bdad44fef1 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -53,6 +53,11 @@ static long cf_check smt_up_down_helper(void *data)
unsigned int cpu, sibling_mask = boot_cpu_data.x86_num_siblings - 1;
int ret = 0;
+ if ( !IS_ENABLED(CONFIG_CPU_HOTPLUG) )
+ {
+ ASSERT_UNREACHABLE();
+ return -EOPNOTSUPP;
+ }
opt_smt = up;
for_each_present_cpu ( cpu )
@@ -121,6 +126,12 @@ long arch_do_sysctl(
long (*fn)(void *data);
void *hcpu;
+ if ( !IS_ENABLED(CONFIG_CPU_HOTPLUG) )
+ {
+ ret = -EOPNOTSUPP;
+ break;
+ }
+
switch ( op )
{
case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index d7e79e752a..0e5b4738a8 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -637,6 +637,14 @@ config SYSTEM_SUSPEND
If unsure, say N.
+config CPU_HOTPLUG
+ bool "CPU online/offline support"
+ depends on X86
+ default y
+ help
+ Enable support for bringing CPUs online and offline at runtime. On
+ X86 this is required for disabling SMT.
+
menu "Supported hypercall interfaces"
visible if EXPERT
--
2.51.2On 30.03.2026 13:59, Mykyta Poturai wrote:
> For the purposes of certification, we want as little code as possible to
> be unconditionally compiled in. Make CPU hotplug and SMT operations
> configurable to ease the process. This will also help with introducing
> CPU hotplug on Arm, where it needs to be configurable.
>
> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Looks largely okay from a technical pov; one nit and one (repeated) remark
below.
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -53,6 +53,11 @@ static long cf_check smt_up_down_helper(void *data)
> unsigned int cpu, sibling_mask = boot_cpu_data.x86_num_siblings - 1;
> int ret = 0;
>
> + if ( !IS_ENABLED(CONFIG_CPU_HOTPLUG) )
> + {
> + ASSERT_UNREACHABLE();
> + return -EOPNOTSUPP;
> + }
> opt_smt = up;
Another blank line above this one perhaps?
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -637,6 +637,14 @@ config SYSTEM_SUSPEND
>
> If unsure, say N.
>
> +config CPU_HOTPLUG
> + bool "CPU online/offline support"
> + depends on X86
> + default y
> + help
> + Enable support for bringing CPUs online and offline at runtime. On
> + X86 this is required for disabling SMT.
The name of this option may need input from others; I'm not quite convinced
that this is a good name, as there's no true "hot-plugging" involved here.
IOW I fear the present name is misleading.
Jan
On 3/30/26 15:19, Jan Beulich wrote:
> On 30.03.2026 13:59, Mykyta Poturai wrote:
>> For the purposes of certification, we want as little code as possible to
>> be unconditionally compiled in. Make CPU hotplug and SMT operations
>> configurable to ease the process. This will also help with introducing
>> CPU hotplug on Arm, where it needs to be configurable.
>>
>> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
>
> Looks largely okay from a technical pov; one nit and one (repeated) remark
> below.
>
>> --- a/xen/arch/x86/sysctl.c
>> +++ b/xen/arch/x86/sysctl.c
>> @@ -53,6 +53,11 @@ static long cf_check smt_up_down_helper(void *data)
>> unsigned int cpu, sibling_mask = boot_cpu_data.x86_num_siblings - 1;
>> int ret = 0;
>>
>> + if ( !IS_ENABLED(CONFIG_CPU_HOTPLUG) )
>> + {
>> + ASSERT_UNREACHABLE();
>> + return -EOPNOTSUPP;
>> + }
>> opt_smt = up;
>
> Another blank line above this one perhaps?
>
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -637,6 +637,14 @@ config SYSTEM_SUSPEND
>>
>> If unsure, say N.
>>
>> +config CPU_HOTPLUG
>> + bool "CPU online/offline support"
>> + depends on X86
>> + default y
>> + help
>> + Enable support for bringing CPUs online and offline at runtime. On
>> + X86 this is required for disabling SMT.
>
> The name of this option may need input from others; I'm not quite convinced
> that this is a good name, as there's no true "hot-plugging" involved here.
> IOW I fear the present name is misleading.
>
> Jan
My first idea was "CONFIG_RUNTIME_CPU_CONTROL" I can switch back to it.
--
Mykyta
On 08.04.2026 14:21, Mykyta Poturai wrote:
> On 3/30/26 15:19, Jan Beulich wrote:
>> On 30.03.2026 13:59, Mykyta Poturai wrote:
>>> For the purposes of certification, we want as little code as possible to
>>> be unconditionally compiled in. Make CPU hotplug and SMT operations
>>> configurable to ease the process. This will also help with introducing
>>> CPU hotplug on Arm, where it needs to be configurable.
>>>
>>> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
>>
>> Looks largely okay from a technical pov; one nit and one (repeated) remark
>> below.
>>
>>> --- a/xen/arch/x86/sysctl.c
>>> +++ b/xen/arch/x86/sysctl.c
>>> @@ -53,6 +53,11 @@ static long cf_check smt_up_down_helper(void *data)
>>> unsigned int cpu, sibling_mask = boot_cpu_data.x86_num_siblings - 1;
>>> int ret = 0;
>>>
>>> + if ( !IS_ENABLED(CONFIG_CPU_HOTPLUG) )
>>> + {
>>> + ASSERT_UNREACHABLE();
>>> + return -EOPNOTSUPP;
>>> + }
>>> opt_smt = up;
>>
>> Another blank line above this one perhaps?
>>
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -637,6 +637,14 @@ config SYSTEM_SUSPEND
>>>
>>> If unsure, say N.
>>>
>>> +config CPU_HOTPLUG
>>> + bool "CPU online/offline support"
>>> + depends on X86
>>> + default y
>>> + help
>>> + Enable support for bringing CPUs online and offline at runtime. On
>>> + X86 this is required for disabling SMT.
>>
>> The name of this option may need input from others; I'm not quite convinced
>> that this is a good name, as there's no true "hot-plugging" involved here.
>> IOW I fear the present name is misleading.
>
> My first idea was "CONFIG_RUNTIME_CPU_CONTROL" I can switch back to it.
I could live with that, for at least not being misleading. CPU_ONLINE or
CPU_ONLINE_OFFLINE might be another option, possibly better suited to
later become a dependency (select) of a true CPU_HOTPLUG. As said, input
from others may be helpful.
Jan
On 4/8/26 15:27, Jan Beulich wrote:
> On 08.04.2026 14:21, Mykyta Poturai wrote:
Hello all.
>> On 3/30/26 15:19, Jan Beulich wrote:
>>> On 30.03.2026 13:59, Mykyta Poturai wrote:
>>>> For the purposes of certification, we want as little code as possible to
>>>> be unconditionally compiled in. Make CPU hotplug and SMT operations
>>>> configurable to ease the process. This will also help with introducing
>>>> CPU hotplug on Arm, where it needs to be configurable.
>>>>
>>>> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
>>>
>>> Looks largely okay from a technical pov; one nit and one (repeated) remark
>>> below.
>>>
>>>> --- a/xen/arch/x86/sysctl.c
>>>> +++ b/xen/arch/x86/sysctl.c
>>>> @@ -53,6 +53,11 @@ static long cf_check smt_up_down_helper(void *data)
>>>> unsigned int cpu, sibling_mask = boot_cpu_data.x86_num_siblings - 1;
>>>> int ret = 0;
>>>>
>>>> + if ( !IS_ENABLED(CONFIG_CPU_HOTPLUG) )
>>>> + {
>>>> + ASSERT_UNREACHABLE();
>>>> + return -EOPNOTSUPP;
>>>> + }
>>>> opt_smt = up;
>>>
>>> Another blank line above this one perhaps?
>>>
>>>> --- a/xen/common/Kconfig
>>>> +++ b/xen/common/Kconfig
>>>> @@ -637,6 +637,14 @@ config SYSTEM_SUSPEND
>>>>
>>>> If unsure, say N.
>>>>
>>>> +config CPU_HOTPLUG
>>>> + bool "CPU online/offline support"
>>>> + depends on X86
>>>> + default y
>>>> + help
>>>> + Enable support for bringing CPUs online and offline at runtime. On
>>>> + X86 this is required for disabling SMT.
>>>
>>> The name of this option may need input from others; I'm not quite convinced
>>> that this is a good name, as there's no true "hot-plugging" involved here.
>>> IOW I fear the present name is misleading.
>>
>> My first idea was "CONFIG_RUNTIME_CPU_CONTROL" I can switch back to it.
>
> I could live with that, for at least not being misleading. CPU_ONLINE or
> CPU_ONLINE_OFFLINE might be another option, possibly better suited to
> later become a dependency (select) of a true CPU_HOTPLUG. As said, input
> from others may be helpful.
To me, CONFIG_RUNTIME_CPU_CONTROL sounds a little bit vague. Although we
are indeed controlling CPUs at runtime, "control" could also mean
cpufreq, power management, affinity pinning. I think
CONFIG_CPU_ONLINE_OFFLINE is more precise, as it is clear from the name
that we are transitioning CPUs between online and offline states.
>
> Jan
>
© 2016 - 2026 Red Hat, Inc.