xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 2/5] x86/idle: re-arrange dead-idle handling
Date: Thu, 06 Dec 2018 01:16:24 -0700	[thread overview]
Message-ID: <5C08DAD802000078002036BB@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <89aaace9-e345-a1ce-7545-48f0b3a59134@citrix.com>

>>> On 05.12.18 at 21:33, <andrew.cooper3@citrix.com> wrote:
> On 10/09/2018 11:13, Jan Beulich wrote:
>>
>>> Equally, it may still be able to service #MC's, so I can't see how it is
>>> safe for us to ever free the percpu data.
>> I'm having trouble seeing how this remark relates to the series here.
> 
> Because you've tried to make NMIs safe, but not made equivalent
> adjustments to the #MC side of things.

Explain to me how this is getting worse with the patch in question.
It doesn't alter under what conditions per-CPU data gets freed.
Of course I can short-circuit the #MC handler just like I do for the
NMI one, but that's only going to delay shutdown of the core
until a second #MC surfaces (as the first one would never get
dealt with).

>> Plus it's a theoretical problem at present only anyway:
>> - physical hot remove is not implemented (there's no source of the
>>   new CPU_REMOVE notification),
>> - Intel CPUs get parked, i.e. never have their per-CPU data freed,
>> - AMD CPUs don't broadcast #MC.
> 
> Ignoring MCE's is never an option, but whenever CR4.MCE is set, we must
> be prepared to handle #MC.  Just because an AMD CPU is playing dead
> doesn't mean it is immune to receiving #MC's.

Again - this is nothing the patch here changes in any way. It's
not clear to me whether clearing CR4.MCE is an option on AMD
CPUs.

Anything beyond wiring #MC into trap_nop() (please let me
know if that's what you want to see added) should imo not
be part of this patch, and again imo doesn't even have to be
part of this series.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-12-06  8:16 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-01 14:22 [PATCH 0/5] x86: more power-efficient CPU parking Jan Beulich
2018-08-01 14:31 ` [PATCH 1/5] x86/cpuidle: replace a pointless NULL check Jan Beulich
2018-08-01 14:33   ` Andrew Cooper
2018-08-01 15:12     ` Jan Beulich
2018-08-01 14:31 ` [PATCH 2/5] x86/idle: re-arrange dead-idle handling Jan Beulich
2018-09-07 17:08   ` Andrew Cooper
2018-09-10 10:13     ` Jan Beulich
2018-10-26 10:55       ` Ping: " Jan Beulich
2018-12-05 20:33       ` Andrew Cooper
2018-12-06  8:16         ` Jan Beulich [this message]
2018-08-01 14:32 ` [PATCH 3/5] x86/cpuidle: push parked CPUs into deeper sleep states when possible Jan Beulich
2018-10-26 10:56   ` Ping: " Jan Beulich
2018-08-01 14:33 ` [PATCH 4/5] x86/cpuidle: clean up Cx dumping Jan Beulich
2018-08-01 14:40   ` Andrew Cooper
2018-08-01 14:33 ` [PATCH 5/5] x86: place non-parked CPUs into wait-for-SIPI state after offlining Jan Beulich
2018-08-29  7:08 ` Ping: [PATCH 0/5] x86: more power-efficient CPU parking Jan Beulich
2018-08-29 17:01   ` Andrew Cooper
2018-08-30  7:29     ` Jan Beulich
     [not found] ` <5B61C21202000000000FC1F1@prv1-mh.provo.novell.com>
     [not found]   ` <5B61C21202000078001F8805@prv1-mh.provo.novell.com>
     [not found]     ` <5B61C21202000000000FC6BD@prv1-mh.provo.novell.com>
     [not found]       ` <5B61C212020000780020B6D8@prv1-mh.provo.novell.com>
     [not found]         ` <5B61C21202000000000FF27E@prv1-mh.provo.novell.com>
     [not found]           ` <5B61C2120200007800224310@prv1-mh.provo.novell.com>
2019-04-03 10:12             ` Jan Beulich
2019-04-03 11:14               ` Andrew Cooper
2019-04-03 12:43                 ` Jan Beulich
2019-04-03 14:44                   ` Andrew Cooper
2019-04-03 15:20                     ` Jan Beulich
     [not found]             ` <5B61C2120200000000101EDC@prv1-mh.provo.novell.com>
     [not found]               ` <5B61C212020000780022FF0D@prv1-mh.provo.novell.com>
2019-05-17 10:10                 ` [PATCH v2 0/3] " Jan Beulich
2019-05-17 10:10                   ` [Xen-devel] " Jan Beulich
2019-05-17 10:11                   ` [PATCH v2 1/3] x86/idle: re-arrange dead-idle handling Jan Beulich
2019-05-17 10:11                     ` [Xen-devel] " Jan Beulich
2019-05-20 14:25                     ` Andrew Cooper
2019-05-20 14:25                       ` [Xen-devel] " Andrew Cooper
2019-05-17 10:12                   ` [PATCH v2 2/3] x86/cpuidle: push parked CPUs into deeper sleep states when possible Jan Beulich
2019-05-17 10:12                     ` [Xen-devel] " Jan Beulich
2019-05-17 10:12                   ` [PATCH v2 3/3] x86/cpuidle: clean up Cx dumping Jan Beulich
2019-05-17 10:12                     ` [Xen-devel] " 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:
  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=5C08DAD802000078002036BB@prv1-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).