Web lists-archives.org

Re: [crash, bisected] Re: [PATCH 3/4] x86_64: Fold pda into per cpu area

Mike Travis wrote:

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().


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. 


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.


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.


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/