All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: fenghua.yu@intel.com, len.brown@intel.com, x86@kernel.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	rob.herring@calxeda.com, grant.likely@secretlab.ca,
	ebiederm@xmission.com, mingo@elte.hu, tglx@linutronix.de,
	vgoyal@redhat.com
Subject: Re: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP
Date: Mon, 22 Oct 2012 09:02:06 -0700	[thread overview]
Message-ID: <50856DFE.8000601@zytor.com> (raw)
In-Reply-To: <20121016.153817.42643171.d.hatayama@jp.fujitsu.com>

On 10/15/2012 11:38 PM, HATAYAMA Daisuke wrote:
>
> Thanks for pointing out this. And I've recalled my investigation in
> the past now. So I want to stop retrying your patch v9 now. This NMI
> method is definitely not applicable to 2nd kernel without any change.
>
> Your NMI method assumes BSP thread is halting in play dead loop. But
> on the 2nd kernel, BSP is halting in the 1st kernel (or possibly in a
> fatail system error). Even if throwing NMI to BSP, it goes back to the
> 1st kernel soon again. I at least confirmed NMI handler is executed in
> this case.
>
> Also, throwing NMI changes stack in the 1st kernel, which is
> unpermissible from kdump's perspective. But x86_64 uses Interrupt
> Stack Table (IST), in which stack switching is not performed. So 2nd
> kernel's stack is used at least on x86_64.
>
> To sum up, to apply NMI method in the 2nd kernel, I think it necessary
> to modify contexts pushed on the stack so execution goes to the 2nd
> kernel's start_secondary() while initializing its state
> appropreately.
>
> Also I think it necessary to discuss whether this NMI method is
> reliable enough for kdump use.
>

I think it's pretty clear it is *not*.  NMI or monitor would either have 
to rely on context set up by the first kernel, which simply isn't safe. 
  Out of those two options, a monitor would actually be safer, since it 
can be self-contained in a completely different way.

However, it seems that running on N-1 CPUs in kdump is perfectly acceptable.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: fenghua.yu@intel.com, linux-kernel@vger.kernel.org,
	kexec@lists.infradead.org, x86@kernel.org, mingo@elte.hu,
	tglx@linutronix.de, len.brown@intel.com, vgoyal@redhat.com,
	ebiederm@xmission.com, grant.likely@secretlab.ca,
	rob.herring@calxeda.com
Subject: Re: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP
Date: Mon, 22 Oct 2012 09:02:06 -0700	[thread overview]
Message-ID: <50856DFE.8000601@zytor.com> (raw)
In-Reply-To: <20121016.153817.42643171.d.hatayama@jp.fujitsu.com>

On 10/15/2012 11:38 PM, HATAYAMA Daisuke wrote:
>
> Thanks for pointing out this. And I've recalled my investigation in
> the past now. So I want to stop retrying your patch v9 now. This NMI
> method is definitely not applicable to 2nd kernel without any change.
>
> Your NMI method assumes BSP thread is halting in play dead loop. But
> on the 2nd kernel, BSP is halting in the 1st kernel (or possibly in a
> fatail system error). Even if throwing NMI to BSP, it goes back to the
> 1st kernel soon again. I at least confirmed NMI handler is executed in
> this case.
>
> Also, throwing NMI changes stack in the 1st kernel, which is
> unpermissible from kdump's perspective. But x86_64 uses Interrupt
> Stack Table (IST), in which stack switching is not performed. So 2nd
> kernel's stack is used at least on x86_64.
>
> To sum up, to apply NMI method in the 2nd kernel, I think it necessary
> to modify contexts pushed on the stack so execution goes to the 2nd
> kernel's start_secondary() while initializing its state
> appropreately.
>
> Also I think it necessary to discuss whether this NMI method is
> reliable enough for kdump use.
>

I think it's pretty clear it is *not*.  NMI or monitor would either have 
to rely on context set up by the first kernel, which simply isn't safe. 
  Out of those two options, a monitor would actually be safer, since it 
can be self-contained in a completely different way.

However, it seems that running on N-1 CPUs in kdump is perfectly acceptable.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


  reply	other threads:[~2012-10-22 16:03 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-16  4:35 [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP HATAYAMA Daisuke
2012-10-16  4:35 ` HATAYAMA Daisuke
2012-10-16  4:35 ` [PATCH v1 1/2] x86, apic: Introduce boot_cpu_is_bsp indicating whether boot cpu is BSP or not HATAYAMA Daisuke
2012-10-16  4:35   ` HATAYAMA Daisuke
2012-10-16  4:35 ` [PATCH v1 2/2] x86, apic: Disable BSP if boot cpu is AP HATAYAMA Daisuke
2012-10-16  4:35   ` HATAYAMA Daisuke
2012-10-22 20:04   ` Eric W. Biederman
2012-10-22 20:04     ` Eric W. Biederman
2012-10-22 20:16     ` H. Peter Anvin
2012-10-22 20:16       ` H. Peter Anvin
2012-10-22 20:31       ` Eric W. Biederman
2012-10-22 20:31         ` Eric W. Biederman
2012-10-22 20:33         ` H. Peter Anvin
2012-10-22 20:33           ` H. Peter Anvin
2012-10-22 20:38           ` H. Peter Anvin
2012-10-22 20:38             ` H. Peter Anvin
2012-10-22 20:43           ` Eric W. Biederman
2012-10-22 20:43             ` Eric W. Biederman
2012-10-22 20:47             ` H. Peter Anvin
2012-10-22 20:47               ` H. Peter Anvin
2012-10-22 21:29               ` Eric W. Biederman
2012-10-22 21:29                 ` Eric W. Biederman
2012-10-23  0:35                 ` H. Peter Anvin
2012-10-23  0:35                   ` H. Peter Anvin
2012-10-26  3:24                   ` HATAYAMA Daisuke
2012-10-26  3:24                     ` HATAYAMA Daisuke
2012-10-26  4:13                     ` Eric W. Biederman
2012-10-26  4:13                       ` Eric W. Biederman
2013-03-11  1:07                       ` HATAYAMA Daisuke
2013-03-11  1:07                         ` HATAYAMA Daisuke
2013-03-11  2:13                         ` HATAYAMA Daisuke
2013-03-11  2:13                           ` HATAYAMA Daisuke
2013-03-11  4:11                           ` H. Peter Anvin
2013-03-11  4:11                             ` H. Peter Anvin
2012-10-16  4:51 ` [PATCH v1 0/2] " Yu, Fenghua
2012-10-16  4:51   ` Yu, Fenghua
2012-10-16  5:03   ` HATAYAMA Daisuke
2012-10-16  5:03     ` HATAYAMA Daisuke
2012-10-16  5:14     ` Yu, Fenghua
2012-10-16  5:14       ` Yu, Fenghua
2012-10-16  6:38       ` HATAYAMA Daisuke
2012-10-16  6:38         ` HATAYAMA Daisuke
2012-10-22 16:02         ` H. Peter Anvin [this message]
2012-10-22 16:02           ` H. Peter Anvin
2012-10-16  5:15     ` HATAYAMA Daisuke
2012-10-16  5:15       ` HATAYAMA Daisuke
2012-10-17 14:12 ` Vivek Goyal
2012-10-17 14:12   ` Vivek Goyal
2012-10-18  3:08   ` HATAYAMA Daisuke
2012-10-18  3:08     ` HATAYAMA Daisuke
2012-10-18 14:14     ` Vivek Goyal
2012-10-18 14:14       ` Vivek Goyal
2012-10-19  3:20       ` HATAYAMA Daisuke
2012-10-19  3:20         ` HATAYAMA Daisuke
2012-10-19 15:17         ` Vivek Goyal
2012-10-19 15:17           ` Vivek Goyal
2012-10-22  6:32           ` HATAYAMA Daisuke
2012-10-22  6:32             ` HATAYAMA Daisuke
2012-10-22 18:37             ` Vivek Goyal
2012-10-22 18:37               ` Vivek Goyal
2012-10-22 17:10           ` Michael Holzheu
2012-10-22 17:10             ` Michael Holzheu

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=50856DFE.8000601@zytor.com \
    --to=hpa@zytor.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=ebiederm@xmission.com \
    --cc=fenghua.yu@intel.com \
    --cc=grant.likely@secretlab.ca \
    --cc=kexec@lists.infradead.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rob.herring@calxeda.com \
    --cc=tglx@linutronix.de \
    --cc=vgoyal@redhat.com \
    --cc=x86@kernel.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.