From: ebiederm@xmission.com (Eric W. Biederman)
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: suparna@in.ibm.com, fastboot@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [KEXEC][PATCH] Modified (smaller) x86 kexec hwfixes patch
Date: 14 Feb 2003 01:30:35 -0700 [thread overview]
Message-ID: <m1adgz8dsk.fsf@frodo.biederman.org> (raw)
In-Reply-To: <23370000.1045195724@[10.10.2.4]>
"Martin J. Bligh" <mbligh@aracnet.com> writes:
> > We still are stopping all cpus on a panic.
> > The difference is that we don't need to move to the boot cpu
> > and do this from there, since the new kernel can deal with
> > starting from any CPU.
>
> The kernel always supported this - cpu IDs are dynamically assigned on
> bootup ... and the boot cpu is always given number 0. There's nothing
> magical about the boot CPU, it doesn't really matter which it is. The only
> problem we had to fix last night was that the OS believes the BIOS mps
> tables as to what the boot CPU is. It now just says ... "oh, I'm the boot
> cpu ... because I'm running this code".
>
> This seems infinitely simpler and safer to me than trying to migrate
> yourself around (potentially at panic time with a bad kernel). The only
> thing that will be different is the *physical* apic id of the CPU, which
> nothing uses after we boot anyway.
At panic time I agree that migration is a bad idea. And the code looks
good for that case. However for booting an arbitrary kernel that code needs
to be run on the original boot strap processor if at all possible. As there
are kernels that cannot cope with booting up on the wrong cpu.
Eric
next prev parent reply other threads:[~2003-02-14 8:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-13 10:40 [KEXEC][PATCH] Modified (smaller) x86 kexec hwfixes patch Suparna Bhattacharya
2003-02-13 15:09 ` Eric W. Biederman
2003-02-14 3:29 ` Suparna Bhattacharya
2003-02-14 4:08 ` Martin J. Bligh
2003-02-14 8:30 ` Eric W. Biederman [this message]
2003-02-14 6:47 ` Martin J. Bligh
2003-02-14 8:32 ` Eric W. Biederman
2003-02-14 15:32 ` Martin J. Bligh
2003-02-14 16:00 ` Eric W. Biederman
2003-02-14 8:39 ` Eric W. Biederman
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=m1adgz8dsk.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=fastboot@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=suparna@in.ibm.com \
/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