All of
 help / color / mirror / Atom feed
From: "Jan Beulich" <>
To: Andrew Cooper <>
Cc: Xen-devel <>,
	Wei Liu <>,
	Roger Pau Monne <>
Subject: Re: [PATCH 3/3] x86/smt: Support for enabling/disabling SMT at runtime
Date: Wed, 03 Apr 2019 06:10:26 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

>>> On 03.04.19 at 13:33, <> wrote:
> On 03/04/2019 11:44, Jan Beulich wrote:
>>>>> On 03.04.19 at 12:17, <> wrote:
>>> On 03/04/2019 10:33, Jan Beulich wrote:
>>>>>>> On 02.04.19 at 21:57, <> wrote:
>>>>> Slightly RFC.  I'm not very happy with the contination situation, but -EBUSY
>>>>> is the preexisting style and it seems like it is the only option from tasklet
>>>>> context.
>>>> Well, offloading the re-invocation to the caller isn't really nice.
>>>> Looking at the code, is there any reason why couldn't use
>>>> the usual -ERESTART / hypercall_create_continuation()? This
>>>> would require a little bit of re-work, in particular to allow
>>>> passing the vCPU into hypercall_create_continuation(), but
>>>> beyond that I can't see any immediate obstacles. Though
>>>> clearly I wouldn't make this a prereq requirement for the work
>>>> here.
>>> The problem isn't really the ERESTART.  We could do some plumbing and
>>> make it work, but the real problem is that I can't stash the current cpu
>>> index in the sysctl data block across the continuation point.
>>> At the moment, the loop depends on, once all CPUs are in the correct
>>> state, getting through the for_each_present_cpu() loop without taking a
>>> further continuation.
>> But these are two orthogonal things: One is how to invoke the
>> continuation, and the other is where the continuation is to
>> resume from. I think the former is more important to address,
>> as it affects how the tools side code needs to look like.
> Right, but -EBUSY is consistent with how the single online/offline ops
> function at the moment, which is why I reused it here.

Right, and which also is why I don't think this has to be taken care
of right now.

>>>>> +    for_each_present_cpu ( cpu )
>>>>> +    {
>>>>> +        if ( cpu == 0 )
>>>>> +            continue;
>>>> Is this special case really needed? If so, perhaps worth a brief
>>>> comment?
>>> Trying to down cpu 0 is a hard -EINVAL.
>> But here we're on the CPU-up path. Plus, for eventually supporting
>> the offlining of CPU 0, it would feel slightly better if you used
>> smp_processor_id() here.
> Are there any processors where you can actually take CPU 0 offline?  Its
> certainly not possible on any Intel or AMD CPUs.
> While I can appreciate the theoretical end goal, it isn't a reality and
> I see no signs of that changing.  Xen very definitely cannot take CPU 0
> offline, nor can hardware, and I don't see any value in jumping through
> hoops for an end goal which doesn't exist.

Interesting. Why was it then that x86 Linux took quite some
steps to make it possible (see BOOTPARAM_HOTPLUG_CPU0
Kconfig option as a possible anchor to locate pieces, which
even has a description of conditions that need to be met in
order for this to be possible)? IOW I'd appreciate clarification
on what it is exactly that you think prevents offlining CPU0
(from a pure hardware / firmware perspective), besides the
PIC and suspend/resume aspects (neither of which has to be
in use) mentioned there.


Xen-devel mailing list

  reply	other threads:[~2019-04-03 12:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-02 19:57 [PATCH 0/3] x86/smt: Runtime SMT controls Andrew Cooper
2019-04-02 19:57 ` [PATCH 1/3] xen/cpu: Distinguish "cpu already in that state" in cpu_{up, down}() Andrew Cooper
2019-04-03  8:49   ` Jan Beulich
2019-04-02 19:57 ` [PATCH 2/3] x86/sysctl: Clean up XEN_SYSCTL_cpu_hotplug Andrew Cooper
2019-04-03  8:53   ` Jan Beulich
2019-04-03  9:06     ` Andrew Cooper
2019-04-03  9:38       ` Jan Beulich
2019-04-04 13:31         ` Andrew Cooper
2019-04-02 19:57 ` [PATCH 3/3] x86/smt: Support for enabling/disabling SMT at runtime Andrew Cooper
2019-04-03  9:33   ` Jan Beulich
2019-04-03 10:17     ` Andrew Cooper
2019-04-03 10:44       ` Jan Beulich
2019-04-03 11:33         ` Andrew Cooper
2019-04-03 12:10           ` Jan Beulich [this message]
2019-04-11  8:16       ` Jan Beulich

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

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