x86-32: Fix crashes with CPU hotplug on AMD machines
in [Kernel]
|
Prev: PCI MSI/MSI-X interrupts support in 2.4.x kernel?
Next: pps: capture MONOTONIC_RAW timestamps as well
From: H. Peter Anvin on 4 Aug 2010 19:10 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 5 Aug 2010 10:20 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 12 Aug 2010 11:50
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/ |