From: H. Peter Anvin on
On 08/04/2010 09:45 AM, Borislav Petkov wrote:
>
> 2. Do not use swapper_pg_dir to boot secondary CPUs like 64-bit
> does.
>
> This patch implements solution 2. It introduces a trampoline_pg_dir
> which has the same layout as swapper_pg_dir with low_mappings. This page
> table is used as the initial page table of the booting CPU. Later in the
> bringup process, it switches to swapper_pg_dir and does a global TLB
> flush. This fixes the crashes in our test cases.
>

I would like to keep around a page directory with the low mappings
around -- and not use it for kernel threads -- at all times *anyway*.
This means we can remove any current hacks that we have to do around S3
entry and exit, for example.

--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -328,7 +328,7 @@ ENTRY(startup_32_smp)
/*
* Enable paging
*/
- movl $pa(swapper_pg_dir),%eax
+ movl pa(initial_page_table), %eax
movl %eax,%cr3 /* set the page table pointer.. */
movl %cr0,%eax
orl $X86_CR0_PG,%eax
@@ -608,6 +608,8 @@ ignore_int:
.align 4
ENTRY(initial_code)
.long i386_start_kernel
+ENTRY(initial_page_table)
+ .long pa(swapper_pg_dir)

/*
* BSS section
@@ -623,6 +625,10 @@ ENTRY(swapper_pg_dir)
#endif
swapper_pg_fixmap:
.fill 1024,4,0
+#ifdef CONFIG_X86_TRAMPOLINE
+ENTRY(trampoline_pg_dir)
+ .fill 1024,4,0
+#endif

I don't really see why this makes sense, though. It would make more
sense that the initial page table we set up becomes trampoline_pg_dir;
we can then set up and change to swapper_pg_dir almost immediately.

I realize this isn't how the 64-bit code works at the moment, but in a
lot of ways I think it would be better if it did.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on
On 08/05/2010 12:45 AM, Roedel, Joerg wrote:
>
> To make sure I understand correctly, you suggest to initialize
> tramponline_pg_dir in the boot sequence of the first cpu and fork
> swapper_pg_dir from it later on?
>

Correct.

>> I realize this isn't how the 64-bit code works at the moment, but in a
>> lot of ways I think it would be better if it did.
>
> Yeah, may make sense. This patch already brings the 32 bit
> implementation closer to the 64 bit one. On 64 bit things are somewhat
> simpler because the tramponline page table can be defined at
> compile-time there (contains only 2 pgd_t entries) while on 32 bit we
> have to initialize it at runtime.

Correct, again. It's unclear to me if we can get away with the very
simple 64-bit approach -- in particular, not including all the 1:1
mappings in the kernel -- for all future users, though.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on
On 08/12/2010 08:47 AM, Borislav Petkov wrote:
>>
>> Agreed. I do have a concern about the kernel page tables not being
>> synchronized into trampoline_pg_dir (it's only an issue for 32-bit
>> !PAE), so at the very least we need to keep an eye out for it...
>
> I've been working on what you suggested and the patch boots on a 32-bit
> PAE kernel but keeps rebooting on non-PAE after setting the stack_start
> on the AP. I could send it out later for you to look at, if you like -
> you should be able to spot what I'm missing :)...
>

Sounds good. This is obviously .37-or-higher material.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/