Mike Travis wrote:
quoted text
> Oh yeah, is it alright to re-use the pda in the static percpu load area
> for each startup cpu, or should it be adjusted to use the areas allocated
> by setup_per_cpu_areas()?  pda_init() is called in x86_64_start_kernel
> so it would only be for anything that occurs before then.  (And I moved
> the call to pda_init() to before the early_idt_handlers are setup.)
>   

Why not use the real pda for all cpus?

Do you move the boot-cpu's per-cpu data? (Please don't)  If not, you can 
just use percpu__pda from the start without having to do anything else, 
and then set up %gs pointing to the pda base for each secondary cpu.

64-bit inherits 32-bit's use of per-cpu gdts, though its mostly useless 
on 64-bit.

More important is to have a:

startup_percpu_base:	.quad	__per_cpu_load

which you stick the processor's initial %gs into, and then load that 
from in startup_secondary_64:

	mov	$X86_MSR_GSBASE, %ecx
	mov	startup_percpu_base, %eax
	mov	startup_percpu_base+4, %edx
	wrmsr

and put

	startup_percpu_base = new_cpus_percpu_base;

in do_cpu_boot().

quoted text
> I hadn't realized that this code is executed for cpus other than the
> boot cpu.  Is there a way to find out if this is the boot cpu (and/or
> the initial execution)?
>   

Don't think so.  If you want something to happen only at boot time, do 
it in startup_64.

quoted text
> If it's the boot cpu, then this would work for the gdt, yes?
>
>         leaq    early_gdt_descr_base(%rip), %edi
>         movq    0(%edi), %rax
>         addq    $__per_cpu_load, %rax
>         movq    %rax, 0(%edi)
>         lgdt    early_gdt_descr(%rip)
>   

As I mentioned in my other mail, a simple add should be enough.

quoted text
> But it should only be executed for the boot because do_boot_cpu()
> does this:
>
>         early_gdt_descr.address = (unsigned long)get_cpu_gdt_table(cpu);
>
> static inline struct desc_struct *get_cpu_gdt_table(unsigned int cpu)
> {
>         return per_cpu(gdt_page, cpu).gdt;
> }
>   

Right, do it in startup_64.

quoted text
> Btw, I've only been testing on an x86_64 system.  I'm sure I've got
> things to fix up for i386.
>   

It should be possible to share almost everything, at least in C.

    J
--
unsubscribe notice
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/