linux-kernel - Re: [crash, bisected] Re: [PATCH 3/4] x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <488A3AEE.4040302@goop.org>
Date:	Fri, 25 Jul 2008 13:43:26 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Mike Travis <travis@....com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jack Steiner <steiner@....com>
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/