SMP GDT setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux