lkml.org 
[lkml]   [2008]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [crash, bisected] Re: [PATCH 3/4] x86_64: Fold pda into per cpu area
Mike Travis wrote:
> Is this for the boot cpu (0), or for all cpus? For the boot cpu, I have
> this now in arch/x86/kernel/setup_percpu.c:
>
> +#ifdef CONFIG_HAVE_ZERO_BASED_PER_CPU
> +
> +/* Initialize percpu offset for boot cpu (0) */
> +unsigned long __per_cpu_offset[NR_CPUS] __read_mostly = {
> + [0] = (unsigned long)__per_cpu_load
> +};
> +#else
> unsigned long __per_cpu_offset[NR_CPUS] __read_mostly;
> +#endif
>
> So this should apply as well to the xen startup?
>

If it's just a static initialization, then it should be fine. But some
equivalent of your head_64.S changes are needed to actually set things up?


>> xen_cpu_up() needs to do whatever initialization needed for a new cpu's
>> percpu area (presumably whatever do_boot_cpu() does).
>>
>>
>
> Does the startup include executing arch/x86/kernel/head_64.S:startup_64() ?
> I see arch/x86/xen/xen-head.S:startup_xen() so I'm guessing not?
>

No, it doesn't. It bypasses all that startup code. Aside from the few
instructions in xen-head.S, xen_start_kernel() is the first thing to get
run.

But when bringing up a secondary cpu, where does the new percpu memory
actually get allocated?

> For the real startup, I do the following two things. But I'm not comfortable
> enough with xen to think I'll get it right putting this in xen-head.S.
>

Yes, it needn't be in the asm code. I'll work out what to do. Looks
like I just need to do an appropriate wrmsr(MSR_GS_BASE, ).

J


\
 
 \ /
  Last update: 2008-07-25 22:45    [W:0.121 / U:0.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site