From: Jan Beulich <jbeulich@suse.com>
To: Mykyta Poturai <Mykyta_Poturai@epam.com>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
"Julien Grall" <julien@xen.org>,
"Bertrand Marquis" <bertrand.marquis@arm.com>,
"Michal Orzel" <michal.orzel@amd.com>,
"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Timothy Pearson" <tpearson@raptorengineering.com>,
"Alistair Francis" <alistair.francis@wdc.com>,
"Connor Davis" <connojdavis@gmail.com>,
"Oleksii Kurochko" <oleksii.kurochko@gmail.com>,
"Daniel P. Smith" <dpsmith@apertussolutions.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v6 3/5] arm/sysctl: Implement cpu hotplug ops
Date: Fri, 27 Mar 2026 12:40:14 +0100 [thread overview]
Message-ID: <99938f35-bbca-4e68-a4ac-4a599e42eede@suse.com> (raw)
In-Reply-To: <eb459343-12a2-4fc1-b26c-efe4fa636aa9@epam.com>
On 27.03.2026 11:39, Mykyta Poturai wrote:
> On 3/23/26 13:09, Jan Beulich wrote:
>> On 12.03.2026 10:39, Mykyta Poturai wrote:
>>> --- 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;
>>
>> I wonder whether on x86 this really should become an optional thing (and
>> if so, whether that wouldn't better be a separate change with proper
>> justification). See also the comment on common/Kconfig further down - by
>> the name of the option, and given the support status the change above may
>> be legitimate, but not some of the similar restrictions added elsewhere.
>
> Maybe force it to be always on like x86 then? I don't really have a
> justification for making it optional on x86, it just happened as side
> effect of creating a config option.
Well, I would have asked for that if there wasn't a (presumed) use case for
making it optional - certification, where as much unused code as possible
(apparently) wants compiling out. You'll need to ask those doing prep work
for certification whether they'd be interested in it becoming optional.
>>> --- a/xen/common/sysctl.c
>>> +++ b/xen/common/sysctl.c
>>> @@ -483,6 +483,52 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
>>> copyback = 1;
>>> break;
>>>
>>> + case XEN_SYSCTL_cpu_hotplug:
>>> + {
>>> + unsigned int cpu = op->u.cpu_hotplug.cpu;
>>
>> I don't think this variable is very useful to keep. Instead use ...
>>
>>> + unsigned int hp_op = op->u.cpu_hotplug.op;
>>> + bool plug;
>>> + long (*fn)(void *data);
>>> + void *hcpu;
>>
>> void *hcpu = _p(op->u.cpu_hotplug.op);
>>
>> right here, dropping the assignments further down.
>>
>>> + ret = -EOPNOTSUPP;
>>> + if ( !IS_ENABLED(CONFIG_CPU_HOTPLUG) )
>>> + break;
>>> +
>>> + switch ( hp_op )
>>> + {
>>> + case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
>>> + plug = true;
>>> + fn = cpu_up_helper;
>>> + hcpu = _p(cpu);
>>> + break;
>>> +
>>> + case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE:
>>> + plug = false;
>>> + fn = cpu_down_helper;
>>> + hcpu = _p(cpu);
>>> + break;
>>> +
>>> + default:
>>> + fn = NULL;
>>> + break;
>>> + }
>>> +
>>> + if ( fn )
>>> + {
>>> + ret = plug ? xsm_resource_plug_core(XSM_HOOK)
>>> + : xsm_resource_unplug_core(XSM_HOOK);
>>> +
>>> + if ( !ret )
>>> + ret = continue_hypercall_on_cpu(0, fn, hcpu);
>>> +
>>> + break;
>>> + }
>>> +
>>> + /* Use the arch handler for cases not handled here */
>>> + fallthrough;
>>> + }
>>> +
>>> default:
>>> ret = arch_do_sysctl(op, u_sysctl);
>>> copyback = 0;
>>
>> This form of falling through may be a little risky, towards someone not
>> looking closely enough and inserting another case label immediately ahead
>> of the default one. While I don't think there's a really good solution to
>> this, please consider
>>
>> }
>> /* Use the arch handler for cases not handled above */
>> fallthrough;
>> default:
>>
>> instead.
>>
>
> Just want to clarirfy if I got the idea. Is this what you meant?
>
> switch ( op->cmd )
> {
> ....
> case XEN_SYSCTL_cpu_hotplug:
> {
> ....
> }
>
> /* Use the arch handler for cases not handled here */
> fallthrough;
> default:
> ret = arch_do_sysctl(op, u_sysctl);
> copyback = 0;
> break;
> }
I can't spot anything different from what I wrote, so (presumably) yes.
Jan
next prev parent reply other threads:[~2026-03-27 11:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-12 9:39 [PATCH v6 0/5] Implement CPU hotplug on Arm Mykyta Poturai
2026-03-12 9:39 ` [PATCH v6 1/5] arm/irq: Keep track of irq affinities Mykyta Poturai
2026-03-18 8:05 ` Bertrand Marquis
2026-03-19 1:34 ` Volodymyr Babchuk
2026-03-19 1:39 ` Volodymyr Babchuk
2026-03-12 9:39 ` [PATCH v6 2/5] arm/irq: Migrate IRQs during CPU up/down operations Mykyta Poturai
2026-03-18 8:12 ` Bertrand Marquis
2026-03-12 9:39 ` [PATCH v6 3/5] arm/sysctl: Implement cpu hotplug ops Mykyta Poturai
2026-03-18 8:23 ` Bertrand Marquis
2026-03-23 11:09 ` Jan Beulich
2026-03-27 10:39 ` Mykyta Poturai
2026-03-27 11:40 ` Jan Beulich [this message]
2026-03-12 9:39 ` [PATCH v6 4/5] tools: Allow building xen-hptool without CONFIG_MIGRATE Mykyta Poturai
2026-03-12 9:39 ` [PATCH v6 5/5] docs: Document CPU hotplug Mykyta Poturai
2026-03-18 8:28 ` Bertrand Marquis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99938f35-bbca-4e68-a4ac-4a599e42eede@suse.com \
--to=jbeulich@suse.com \
--cc=Mykyta_Poturai@epam.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=alistair.francis@wdc.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=bertrand.marquis@arm.com \
--cc=connojdavis@gmail.com \
--cc=dpsmith@apertussolutions.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=oleksii.kurochko@gmail.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=tpearson@raptorengineering.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.