lkml.org 
[lkml]   [2006]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectSMP GDT setup
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-08-31 21:07    [W:0.024 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site