public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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