* [PATCH 3/7] x86/efi/32: Fix EFI on systems where the percpu GDT is virtually mapped [not found] ` <cover.1490218061.git.luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> @ 2017-03-22 21:32 ` Andy Lutomirski 2017-03-22 21:32 ` [PATCH 4/7] x86/boot/32: Defer resyncing initial_page_table until percpu is set up Andy Lutomirski 1 sibling, 0 replies; 10+ messages in thread From: Andy Lutomirski @ 2017-03-22 21:32 UTC (permalink / raw) To: x86-DgEjT+Ai2ygdnm+yROfE0A Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Borislav Petkov, Boris Ostrovsky, Juergen Gross, Thomas Garnier, Andy Lutomirski, Matt Fleming, Ard Biesheuvel, linux-efi-u79uwXL29TY76Z2rM5mHXA __pa on a percpu pointer is invalid. This bug appears to go *waaay* back, and I guess it's just never been triggered. Cc: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> Cc: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Signed-off-by: Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> --- arch/x86/platform/efi/efi_32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/platform/efi/efi_32.c b/arch/x86/platform/efi/efi_32.c index 950071171436..3481268da3d0 100644 --- a/arch/x86/platform/efi/efi_32.c +++ b/arch/x86/platform/efi/efi_32.c @@ -68,7 +68,7 @@ pgd_t * __init efi_call_phys_prolog(void) load_cr3(initial_page_table); __flush_tlb_all(); - gdt_descr.address = __pa(get_cpu_gdt_rw(0)); + gdt_descr.address = get_cpu_gdt_paddr(0); gdt_descr.size = GDT_SIZE - 1; load_gdt(&gdt_descr); -- 2.9.3 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 4/7] x86/boot/32: Defer resyncing initial_page_table until percpu is set up [not found] ` <cover.1490218061.git.luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2017-03-22 21:32 ` [PATCH 3/7] x86/efi/32: Fix EFI on systems where the percpu GDT is virtually mapped Andy Lutomirski @ 2017-03-22 21:32 ` Andy Lutomirski [not found] ` <tip-23b2a4ddebdd17fad265b4bb77256c2e4ec37dee@git.kernel.org> 1 sibling, 1 reply; 10+ messages in thread From: Andy Lutomirski @ 2017-03-22 21:32 UTC (permalink / raw) To: x86-DgEjT+Ai2ygdnm+yROfE0A Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Borislav Petkov, Boris Ostrovsky, Juergen Gross, Thomas Garnier, Andy Lutomirski, Matt Fleming, Ard Biesheuvel, linux-efi-u79uwXL29TY76Z2rM5mHXA The x86 smpboot trampoline expects initial_page_table to have the GDT mapped. If the GDT ends up in a virtually mapped percpu page, then it won't be in the page tables at all until percpu areas are set up. The result will be a triple fault the first time that the CPU attempts to access the GDT after LGDT loads the percpu GDT. This appears to be an old bug, but somehow the GDT fixmap rework is triggering it. This seems to have something to do with the memory layout. Cc: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> Cc: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Signed-off-by: Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> --- arch/x86/kernel/setup.c | 15 --------------- arch/x86/kernel/setup_percpu.c | 21 +++++++++++++++++++++ 2 files changed, 21 insertions(+), 15 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 4bf0c8926a1c..56b1177155db 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1226,21 +1226,6 @@ void __init setup_arch(char **cmdline_p) kasan_init(); -#ifdef CONFIG_X86_32 - /* sync back kernel address range */ - clone_pgd_range(initial_page_table + KERNEL_PGD_BOUNDARY, - swapper_pg_dir + KERNEL_PGD_BOUNDARY, - KERNEL_PGD_PTRS); - - /* - * sync back low identity map too. It is used for example - * in the 32-bit EFI stub. - */ - clone_pgd_range(initial_page_table, - swapper_pg_dir + KERNEL_PGD_BOUNDARY, - min(KERNEL_PGD_PTRS, KERNEL_PGD_BOUNDARY)); -#endif - tboot_probe(); map_vsyscall(); diff --git a/arch/x86/kernel/setup_percpu.c b/arch/x86/kernel/setup_percpu.c index 11338b0b3ad2..bb1e8cc0bc84 100644 --- a/arch/x86/kernel/setup_percpu.c +++ b/arch/x86/kernel/setup_percpu.c @@ -288,4 +288,25 @@ void __init setup_per_cpu_areas(void) /* Setup cpu initialized, callin, callout masks */ setup_cpu_local_masks(); + +#ifdef CONFIG_X86_32 + /* + * Sync back kernel address range. We want to make sure that + * all kernel mappings, including percpu mappings, are available + * in the smpboot asm. We can't reliably pick up percpu + * mappings using vmalloc_fault(), because exception dispatch + * needs percpu data. + */ + clone_pgd_range(initial_page_table + KERNEL_PGD_BOUNDARY, + swapper_pg_dir + KERNEL_PGD_BOUNDARY, + KERNEL_PGD_PTRS); + + /* + * sync back low identity map too. It is used for example + * in the 32-bit EFI stub. + */ + clone_pgd_range(initial_page_table, + swapper_pg_dir + KERNEL_PGD_BOUNDARY, + min(KERNEL_PGD_PTRS, KERNEL_PGD_BOUNDARY)); +#endif } -- 2.9.3 ^ permalink raw reply related [flat|nested] 10+ messages in thread
[parent not found: <tip-23b2a4ddebdd17fad265b4bb77256c2e4ec37dee@git.kernel.org>]
[parent not found: <tip-23b2a4ddebdd17fad265b4bb77256c2e4ec37dee-Ckxz5ZWcFp/9qxiX1TGQuw@public.gmane.org>]
* Re: [tip:x86/mm] x86/boot/32: Defer resyncing initial_page_table until per-cpu is set up [not found] ` <tip-23b2a4ddebdd17fad265b4bb77256c2e4ec37dee-Ckxz5ZWcFp/9qxiX1TGQuw@public.gmane.org> @ 2017-05-08 6:31 ` Jan Kiszka [not found] ` <0c4d6d04-7038-fb82-87b3-343784550d0a-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: Jan Kiszka @ 2017-05-08 6:31 UTC (permalink / raw) To: luto-DgEjT+Ai2ygdnm+yROfE0A, mingo-DgEjT+Ai2ygdnm+yROfE0A, x86, linux-efi Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, peterz-wEGCiKHe2LqWVfeAwA7xHQ, torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, jpoimboe-H+wXaHxf7aLQT0dZR+AlfA, boris.ostrovsky-QHcLZuEGTsvQT0dZR+AlfA, bp-Gina5bIWoIWzQB+pC5nmwQ, hpa-YMNOUZJC4hwAvxtiuMwx3w, matt-mF/unelCI9GS6iBeEJttW/XRex20P6io, tglx-hfZtesqFncYOwBW4kG4KsQ, brgerst-Re5JQEeQqe8AvxtiuMwx3w, thgarnie-hpIqsD4AKlfQT0dZR+AlfA, dvlasenk-H+wXaHxf7aLQT0dZR+AlfA, jgross-IBi9RG/b67k, ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A On 2017-03-23 10:14, tip-bot for Andy Lutomirski wrote: > The x86 smpboot trampoline expects initial_page_table to have the > GDT mapped. If the GDT ends up in a virtually mapped per-cpu page, > then it won't be in the page tables at all until perc-pu areas are > set up. The result will be a triple fault the first time that the > CPU attempts to access the GDT after LGDT loads the perc-pu GDT. > > This appears to be an old bug, but somehow the GDT fixmap rework > is triggering it. This seems to have something to do with the > memory layout. > > Signed-off-by: Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > Cc: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > Cc: Boris Ostrovsky <boris.ostrovsky-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> > Cc: Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org> > Cc: Brian Gerst <brgerst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Cc: Denys Vlasenko <dvlasenk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > Cc: H. Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> > Cc: Josh Poimboeuf <jpoimboe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > Cc: Juergen Gross <jgross-IBi9RG/b67k@public.gmane.org> > Cc: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> > Cc: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> > Cc: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> > Cc: Thomas Garnier <thgarnie-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> > Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org> > Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > Link: http://lkml.kernel.org/r/a553264a5972c6a86f9b5caac237470a0c74a720.1490218061.git.luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org > Signed-off-by: Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > --- > arch/x86/kernel/setup.c | 15 --------------- > arch/x86/kernel/setup_percpu.c | 21 +++++++++++++++++++++ > 2 files changed, 21 insertions(+), 15 deletions(-) > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index 4bf0c89..56b1177 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -1226,21 +1226,6 @@ void __init setup_arch(char **cmdline_p) > > kasan_init(); > > -#ifdef CONFIG_X86_32 > - /* sync back kernel address range */ > - clone_pgd_range(initial_page_table + KERNEL_PGD_BOUNDARY, > - swapper_pg_dir + KERNEL_PGD_BOUNDARY, > - KERNEL_PGD_PTRS); > - > - /* > - * sync back low identity map too. It is used for example > - * in the 32-bit EFI stub. > - */ > - clone_pgd_range(initial_page_table, > - swapper_pg_dir + KERNEL_PGD_BOUNDARY, > - min(KERNEL_PGD_PTRS, KERNEL_PGD_BOUNDARY)); > -#endif > - > tboot_probe(); > > map_vsyscall(); > diff --git a/arch/x86/kernel/setup_percpu.c b/arch/x86/kernel/setup_percpu.c > index 11338b0..bb1e8cc 100644 > --- a/arch/x86/kernel/setup_percpu.c > +++ b/arch/x86/kernel/setup_percpu.c > @@ -288,4 +288,25 @@ void __init setup_per_cpu_areas(void) > > /* Setup cpu initialized, callin, callout masks */ > setup_cpu_local_masks(); > + > +#ifdef CONFIG_X86_32 > + /* > + * Sync back kernel address range. We want to make sure that > + * all kernel mappings, including percpu mappings, are available > + * in the smpboot asm. We can't reliably pick up percpu > + * mappings using vmalloc_fault(), because exception dispatch > + * needs percpu data. > + */ > + clone_pgd_range(initial_page_table + KERNEL_PGD_BOUNDARY, > + swapper_pg_dir + KERNEL_PGD_BOUNDARY, > + KERNEL_PGD_PTRS); > + > + /* > + * sync back low identity map too. It is used for example > + * in the 32-bit EFI stub. > + */ > + clone_pgd_range(initial_page_table, > + swapper_pg_dir + KERNEL_PGD_BOUNDARY, > + min(KERNEL_PGD_PTRS, KERNEL_PGD_BOUNDARY)); > +#endif > } > This breaks the boot on our Intel Quark platform (IOT2000, similar to Galileo Gen2). Reverting it over master makes it work again. Any idea what goes wrong? Let me know how I can help debugging this. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <0c4d6d04-7038-fb82-87b3-343784550d0a-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org>]
* Re: [tip:x86/mm] x86/boot/32: Defer resyncing initial_page_table until per-cpu is set up [not found] ` <0c4d6d04-7038-fb82-87b3-343784550d0a-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> @ 2017-05-08 9:32 ` Andy Shevchenko [not found] ` <CAHp75VdX-kUqW0MKOSTz9zByU-eipBMnKpdUbTt2SVOJ8Kvrig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: Andy Shevchenko @ 2017-05-08 9:32 UTC (permalink / raw) To: Jan Kiszka Cc: Andy Lutomirski, Ingo Molnar, x86, linux-efi, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Peter Zijlstra (Intel), Linus Torvalds, jpoimboe-H+wXaHxf7aLQT0dZR+AlfA, Boris Ostrovsky, Borislav Petkov, H. Peter Anvin, Matt Fleming, Thomas Gleixner, Brian Gerst, thgarnie-hpIqsD4AKlfQT0dZR+AlfA, Denys Vlasenko, Juergen Gross, Ard Biesheuvel On Mon, May 8, 2017 at 9:31 AM, Jan Kiszka <jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> wrote: > On 2017-03-23 10:14, tip-bot for Andy Lutomirski wrote: >> The x86 smpboot trampoline expects initial_page_table to have the >> GDT mapped. If the GDT ends up in a virtually mapped per-cpu page, >> then it won't be in the page tables at all until perc-pu areas are >> set up. The result will be a triple fault the first time that the >> CPU attempts to access the GDT after LGDT loads the perc-pu GDT. >> >> This appears to be an old bug, but somehow the GDT fixmap rework >> is triggering it. This seems to have something to do with the >> memory layout. > This breaks the boot on our Intel Quark platform (IOT2000, similar to > Galileo Gen2). Reverting it over master makes it work again. Any idea > what goes wrong? Let me know how I can help debugging this. JFYI: As of today linux-next when _kexec:ed_ works fine to me Perhaps I can test this later with direct boot from SD card. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <CAHp75VdX-kUqW0MKOSTz9zByU-eipBMnKpdUbTt2SVOJ8Kvrig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [tip:x86/mm] x86/boot/32: Defer resyncing initial_page_table until per-cpu is set up [not found] ` <CAHp75VdX-kUqW0MKOSTz9zByU-eipBMnKpdUbTt2SVOJ8Kvrig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2017-05-08 11:21 ` Andy Lutomirski 2017-05-08 12:34 ` Jan Kiszka 0 siblings, 1 reply; 10+ messages in thread From: Andy Lutomirski @ 2017-05-08 11:21 UTC (permalink / raw) To: Andy Shevchenko Cc: Jan Kiszka, Andy Lutomirski, Ingo Molnar, x86, linux-efi, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Peter Zijlstra (Intel), Linus Torvalds, Josh Poimboeuf, Boris Ostrovsky, Borislav Petkov, H. Peter Anvin, Matt Fleming, Thomas Gleixner, Brian Gerst, Thomas Garnier, Denys Vlasenko, Juergen Gross, Ard Biesheuvel On Mon, May 8, 2017 at 2:32 AM, Andy Shevchenko <andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > On Mon, May 8, 2017 at 9:31 AM, Jan Kiszka <jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> wrote: >> On 2017-03-23 10:14, tip-bot for Andy Lutomirski wrote: >>> The x86 smpboot trampoline expects initial_page_table to have the >>> GDT mapped. If the GDT ends up in a virtually mapped per-cpu page, >>> then it won't be in the page tables at all until perc-pu areas are >>> set up. The result will be a triple fault the first time that the >>> CPU attempts to access the GDT after LGDT loads the perc-pu GDT. >>> >>> This appears to be an old bug, but somehow the GDT fixmap rework >>> is triggering it. This seems to have something to do with the >>> memory layout. > >> This breaks the boot on our Intel Quark platform (IOT2000, similar to >> Galileo Gen2). Reverting it over master makes it work again. Any idea >> what goes wrong? Let me know how I can help debugging this. > > JFYI: As of today linux-next when _kexec:ed_ works fine to me > > Perhaps I can test this later with direct boot from SD card. > The most likely explanation is that there's some code that needs the page table synced and runs before setup_per_cpu_areas(). The relevant init code is: setup_arch(&command_line); mm_init_cpumask(&init_mm); setup_command_line(command_line); setup_nr_cpu_ids(); setup_per_cpu_areas(); so I didn't move it very far. It would be awesome if we could get a backtrace when the failure happens, but it's likely to be a triple fault. Is this an EFI boot? I bet the failure is in efi_init(). Could you try reverting just the deletions in the patch? I.e. try a kernel with both the old and the new copies of the code I moved. --Andy ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [tip:x86/mm] x86/boot/32: Defer resyncing initial_page_table until per-cpu is set up 2017-05-08 11:21 ` Andy Lutomirski @ 2017-05-08 12:34 ` Jan Kiszka [not found] ` <7f5916b5-01c0-52d5-9f44-dee4bf355212-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: Jan Kiszka @ 2017-05-08 12:34 UTC (permalink / raw) To: Andy Lutomirski, Andy Shevchenko Cc: Ingo Molnar, x86, linux-efi, linux-kernel, Peter Zijlstra (Intel), Linus Torvalds, Josh Poimboeuf, Boris Ostrovsky, Borislav Petkov, H. Peter Anvin, Matt Fleming, Thomas Gleixner, Brian Gerst, Thomas Garnier, Denys Vlasenko, Juergen Gross, Ard Biesheuvel On 2017-05-08 13:21, Andy Lutomirski wrote: > On Mon, May 8, 2017 at 2:32 AM, Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: >> On Mon, May 8, 2017 at 9:31 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote: >>> On 2017-03-23 10:14, tip-bot for Andy Lutomirski wrote: >>>> The x86 smpboot trampoline expects initial_page_table to have the >>>> GDT mapped. If the GDT ends up in a virtually mapped per-cpu page, >>>> then it won't be in the page tables at all until perc-pu areas are >>>> set up. The result will be a triple fault the first time that the >>>> CPU attempts to access the GDT after LGDT loads the perc-pu GDT. >>>> >>>> This appears to be an old bug, but somehow the GDT fixmap rework >>>> is triggering it. This seems to have something to do with the >>>> memory layout. >> >>> This breaks the boot on our Intel Quark platform (IOT2000, similar to >>> Galileo Gen2). Reverting it over master makes it work again. Any idea >>> what goes wrong? Let me know how I can help debugging this. >> >> JFYI: As of today linux-next when _kexec:ed_ works fine to me >> >> Perhaps I can test this later with direct boot from SD card. >> > > The most likely explanation is that there's some code that needs the > page table synced and runs before setup_per_cpu_areas(). The relevant > init code is: > > setup_arch(&command_line); > mm_init_cpumask(&init_mm); > setup_command_line(command_line); > setup_nr_cpu_ids(); > setup_per_cpu_areas(); > > so I didn't move it very far. It would be awesome if we could get a > backtrace when the failure happens, but it's likely to be a triple > fault. Is this an EFI boot? I bet the failure is in efi_init(). Yes, it's an EFI thing. Unfortunately, I didn't make earlycon/earlyprintk work yet. > > Could you try reverting just the deletions in the patch? I.e. try a > kernel with both the old and the new copies of the code I moved. Let me try that later. I can also move the new code around to nail down the dependency. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <7f5916b5-01c0-52d5-9f44-dee4bf355212-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org>]
* Re: [tip:x86/mm] x86/boot/32: Defer resyncing initial_page_table until per-cpu is set up [not found] ` <7f5916b5-01c0-52d5-9f44-dee4bf355212-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> @ 2017-05-08 14:45 ` Andy Shevchenko 2017-05-08 15:24 ` Jan Kiszka 2017-05-08 17:53 ` Jan Kiszka 1 sibling, 1 reply; 10+ messages in thread From: Andy Shevchenko @ 2017-05-08 14:45 UTC (permalink / raw) To: Jan Kiszka Cc: Andy Lutomirski, Ingo Molnar, x86, linux-efi, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Peter Zijlstra (Intel), Linus Torvalds, Josh Poimboeuf, Boris Ostrovsky, Borislav Petkov, H. Peter Anvin, Matt Fleming, Thomas Gleixner, Brian Gerst, Thomas Garnier, Denys Vlasenko, Juergen Gross, Ard Biesheuvel On Mon, May 8, 2017 at 3:34 PM, Jan Kiszka <jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> wrote: > On 2017-05-08 13:21, Andy Lutomirski wrote: > Yes, it's an EFI thing. Unfortunately, I didn't make > earlycon/earlyprintk work yet. Quark does use HS UART for the console and we have no support for such in x86/earlyprintk. earlycon should work if you add proper parameters to the command line (including port base address, no ttySx), though I don't remember if it makes really "early". -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [tip:x86/mm] x86/boot/32: Defer resyncing initial_page_table until per-cpu is set up 2017-05-08 14:45 ` Andy Shevchenko @ 2017-05-08 15:24 ` Jan Kiszka 0 siblings, 0 replies; 10+ messages in thread From: Jan Kiszka @ 2017-05-08 15:24 UTC (permalink / raw) To: Andy Shevchenko Cc: Andy Lutomirski, Ingo Molnar, x86, linux-efi, linux-kernel, Peter Zijlstra (Intel), Linus Torvalds, Josh Poimboeuf, Boris Ostrovsky, Borislav Petkov, H. Peter Anvin, Matt Fleming, Thomas Gleixner, Brian Gerst, Thomas Garnier, Denys Vlasenko, Juergen Gross, Ard Biesheuvel On 2017-05-08 16:45, Andy Shevchenko wrote: > On Mon, May 8, 2017 at 3:34 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote: >> On 2017-05-08 13:21, Andy Lutomirski wrote: > >> Yes, it's an EFI thing. Unfortunately, I didn't make >> earlycon/earlyprintk work yet. > > Quark does use HS UART for the console and we have no support for such > in x86/earlyprintk. earlycon should work if you add proper parameters > to the command line (including port base address, no ttySx), though I > don't remember if it makes really "early". Ah, that explains it. I've tried earlycon, also with the apparently correct params, but it didn't print anything in this case. And earlyprintk=efi seems to use a framebuffer, while our devices are headless... Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [tip:x86/mm] x86/boot/32: Defer resyncing initial_page_table until per-cpu is set up [not found] ` <7f5916b5-01c0-52d5-9f44-dee4bf355212-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> 2017-05-08 14:45 ` Andy Shevchenko @ 2017-05-08 17:53 ` Jan Kiszka [not found] ` <7ce941e5-5a9b-acd7-c7b6-7be464572de5-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> 1 sibling, 1 reply; 10+ messages in thread From: Jan Kiszka @ 2017-05-08 17:53 UTC (permalink / raw) To: Andy Lutomirski, Andy Shevchenko Cc: Ingo Molnar, x86, linux-efi, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Peter Zijlstra (Intel), Linus Torvalds, Josh Poimboeuf, Boris Ostrovsky, Borislav Petkov, H. Peter Anvin, Matt Fleming, Thomas Gleixner, Brian Gerst, Thomas Garnier, Denys Vlasenko, Juergen Gross, Ard Biesheuvel On 2017-05-08 14:34, Jan Kiszka wrote: > On 2017-05-08 13:21, Andy Lutomirski wrote: >> On Mon, May 8, 2017 at 2:32 AM, Andy Shevchenko >> <andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >>> On Mon, May 8, 2017 at 9:31 AM, Jan Kiszka <jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> wrote: >>>> On 2017-03-23 10:14, tip-bot for Andy Lutomirski wrote: >>>>> The x86 smpboot trampoline expects initial_page_table to have the >>>>> GDT mapped. If the GDT ends up in a virtually mapped per-cpu page, >>>>> then it won't be in the page tables at all until perc-pu areas are >>>>> set up. The result will be a triple fault the first time that the >>>>> CPU attempts to access the GDT after LGDT loads the perc-pu GDT. >>>>> >>>>> This appears to be an old bug, but somehow the GDT fixmap rework >>>>> is triggering it. This seems to have something to do with the >>>>> memory layout. >>> >>>> This breaks the boot on our Intel Quark platform (IOT2000, similar to >>>> Galileo Gen2). Reverting it over master makes it work again. Any idea >>>> what goes wrong? Let me know how I can help debugging this. >>> >>> JFYI: As of today linux-next when _kexec:ed_ works fine to me >>> >>> Perhaps I can test this later with direct boot from SD card. >>> >> >> The most likely explanation is that there's some code that needs the >> page table synced and runs before setup_per_cpu_areas(). The relevant >> init code is: >> >> setup_arch(&command_line); >> mm_init_cpumask(&init_mm); >> setup_command_line(command_line); >> setup_nr_cpu_ids(); >> setup_per_cpu_areas(); >> >> so I didn't move it very far. It would be awesome if we could get a >> backtrace when the failure happens, but it's likely to be a triple >> fault. Is this an EFI boot? I bet the failure is in efi_init(). > > Yes, it's an EFI thing. Unfortunately, I didn't make > earlycon/earlyprintk work yet. > >> >> Could you try reverting just the deletions in the patch? I.e. try a >> kernel with both the old and the new copies of the code I moved. > > Let me try that later. I can also move the new code around to nail down > the dependency. > I found the reason: your patch is very discriminating! Not the whole world is multicore yet. ;) setup_per_cpu_areas() is taken from mm/percpu.c in case of !CONFIG_SMP. So the new home for the resync is not even built. Any suggestions how to refactor things instead? Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <7ce941e5-5a9b-acd7-c7b6-7be464572de5-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org>]
* Re: [tip:x86/mm] x86/boot/32: Defer resyncing initial_page_table until per-cpu is set up [not found] ` <7ce941e5-5a9b-acd7-c7b6-7be464572de5-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> @ 2017-05-09 0:03 ` Andy Lutomirski 0 siblings, 0 replies; 10+ messages in thread From: Andy Lutomirski @ 2017-05-09 0:03 UTC (permalink / raw) To: Jan Kiszka Cc: Andy Lutomirski, Andy Shevchenko, Ingo Molnar, x86, linux-efi, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Peter Zijlstra (Intel), Linus Torvalds, Josh Poimboeuf, Boris Ostrovsky, Borislav Petkov, H. Peter Anvin, Matt Fleming, Thomas Gleixner, Brian Gerst, Thomas Garnier, Denys Vlasenko, Juergen Gross, Ard Biesheuvel On Mon, May 8, 2017 at 10:53 AM, Jan Kiszka <jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> wrote: > On 2017-05-08 14:34, Jan Kiszka wrote: >> On 2017-05-08 13:21, Andy Lutomirski wrote: >>> On Mon, May 8, 2017 at 2:32 AM, Andy Shevchenko >>> <andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >>>> On Mon, May 8, 2017 at 9:31 AM, Jan Kiszka <jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> wrote: >>>>> On 2017-03-23 10:14, tip-bot for Andy Lutomirski wrote: >>>>>> The x86 smpboot trampoline expects initial_page_table to have the >>>>>> GDT mapped. If the GDT ends up in a virtually mapped per-cpu page, >>>>>> then it won't be in the page tables at all until perc-pu areas are >>>>>> set up. The result will be a triple fault the first time that the >>>>>> CPU attempts to access the GDT after LGDT loads the perc-pu GDT. >>>>>> >>>>>> This appears to be an old bug, but somehow the GDT fixmap rework >>>>>> is triggering it. This seems to have something to do with the >>>>>> memory layout. >>>> >>>>> This breaks the boot on our Intel Quark platform (IOT2000, similar to >>>>> Galileo Gen2). Reverting it over master makes it work again. Any idea >>>>> what goes wrong? Let me know how I can help debugging this. >>>> >>>> JFYI: As of today linux-next when _kexec:ed_ works fine to me >>>> >>>> Perhaps I can test this later with direct boot from SD card. >>>> >>> >>> The most likely explanation is that there's some code that needs the >>> page table synced and runs before setup_per_cpu_areas(). The relevant >>> init code is: >>> >>> setup_arch(&command_line); >>> mm_init_cpumask(&init_mm); >>> setup_command_line(command_line); >>> setup_nr_cpu_ids(); >>> setup_per_cpu_areas(); >>> >>> so I didn't move it very far. It would be awesome if we could get a >>> backtrace when the failure happens, but it's likely to be a triple >>> fault. Is this an EFI boot? I bet the failure is in efi_init(). >> >> Yes, it's an EFI thing. Unfortunately, I didn't make >> earlycon/earlyprintk work yet. >> >>> >>> Could you try reverting just the deletions in the patch? I.e. try a >>> kernel with both the old and the new copies of the code I moved. >> >> Let me try that later. I can also move the new code around to nail down >> the dependency. >> > > I found the reason: your patch is very discriminating! Not the whole > world is multicore yet. ;) > > setup_per_cpu_areas() is taken from mm/percpu.c in case of !CONFIG_SMP. > So the new home for the resync is not even built. D'oh! > > Any suggestions how to refactor things instead? efi_init() seems okay, but it makes me nervous. I think the partial revert is the right fix. Patch coming. > > Jan > > -- > Siemens AG, Corporate Technology, CT RDA ITP SES-DE > Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-05-09 0:03 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <cover.1490218061.git.luto@kernel.org> [not found] ` <cover.1490218061.git.luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2017-03-22 21:32 ` [PATCH 3/7] x86/efi/32: Fix EFI on systems where the percpu GDT is virtually mapped Andy Lutomirski 2017-03-22 21:32 ` [PATCH 4/7] x86/boot/32: Defer resyncing initial_page_table until percpu is set up Andy Lutomirski [not found] ` <tip-23b2a4ddebdd17fad265b4bb77256c2e4ec37dee@git.kernel.org> [not found] ` <tip-23b2a4ddebdd17fad265b4bb77256c2e4ec37dee-Ckxz5ZWcFp/9qxiX1TGQuw@public.gmane.org> 2017-05-08 6:31 ` [tip:x86/mm] x86/boot/32: Defer resyncing initial_page_table until per-cpu " Jan Kiszka [not found] ` <0c4d6d04-7038-fb82-87b3-343784550d0a-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> 2017-05-08 9:32 ` Andy Shevchenko [not found] ` <CAHp75VdX-kUqW0MKOSTz9zByU-eipBMnKpdUbTt2SVOJ8Kvrig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-05-08 11:21 ` Andy Lutomirski 2017-05-08 12:34 ` Jan Kiszka [not found] ` <7f5916b5-01c0-52d5-9f44-dee4bf355212-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> 2017-05-08 14:45 ` Andy Shevchenko 2017-05-08 15:24 ` Jan Kiszka 2017-05-08 17:53 ` Jan Kiszka [not found] ` <7ce941e5-5a9b-acd7-c7b6-7be464572de5-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> 2017-05-09 0:03 ` Andy Lutomirski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).