From: Jeremy Fitzhardinge <jeremy@goop.org>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Zachary Amsden <zach@vmware.com>,
Matt Tolentino <metolent@snoqualmie.dp.intel.com>,
Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>
Subject: SMP GDT setup
Date: Thu, 31 Aug 2006 12:05:38 -0700 [thread overview]
Message-ID: <44F73302.9000800@goop.org> (raw)
Hi,
I've been working on a set of patches to implement per-processor data
areas for i386, and changes to current and smp_processor_id() to take
advantage of the PDA. The implementation relies on the per-CPU GDT to
set up a descriptor to the PDA memory, and then point %gs at that memory
within the kernel. In other words, very similar to the x86-64 PDA
implementation. (Posted to lkml yesterday, "Implement per-processor
data areas for i386." and followups.)
This works well, but there is a window early in CPU bringup where the
PDA has not been set up, and so smp_processor_id() and current are not
usable. For now, I'm defining early_* versions of these operations,
which fall back to using the thread_info structure. For the boot CPU,
I'm currently setting up an early boot-time PDA corresponding to the
boot-time GDT, which is replaced in cpu_init().
For secondary CPUs, I'm currently allocating the GDT and PDA on the boot
CPU before bringing up the secondary, so I can avoid doing allocation
before setting up the PDA (since the allocation code uses current). It
would be nice to have the PDA set up much earlier so that this is not an
issue. Almost all the work can be done in advance before bringing up
the secondary, and then head.S can simply lgdt its GDT and set %gs
before even hitting C code, so that smp_processor_id and current will
always work in C code.
I was thinking about how to go about doing this, and from looking over
the history of common/cpu.c, it seems that my contemplated changes (use
a static GDT and PDA for the boot CPU; use a simple cpu-id indexed array
for other CPU GDT descrpitors and PDAs rather than using percpu()) would
substantially revert your changes from 25 Feb 2006: "x86: fix broken SMP
boot sequence", change 2b932f6cf052920fb3a6281499e08209b08f5086.
So, I'm wondering if you have any thoughts or suggestions for how I
might go about doing this?
Thanks,
J
reply other threads:[~2006-08-31 19:05 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=44F73302.9000800@goop.org \
--to=jeremy@goop.org \
--cc=James.Bottomley@SteelEye.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=metolent@snoqualmie.dp.intel.com \
--cc=torvalds@osdl.org \
--cc=zach@vmware.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