From: "H. Peter Anvin" <hpa@zytor.com>
To: Borislav Petkov <bp@amd64.org>
Cc: mingo@elte.hu, tglx@linutronix.de, andreas.herrmann3@amd.com,
conny.seidel@amd.com, joerg.roedel@amd.com,
Bhavna.Sarathy@amd.com, greg@kroah.com, x86@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] x86-32: Fix crashes with CPU hotplug on AMD machines
Date: Wed, 04 Aug 2010 16:05:47 -0700 [thread overview]
Message-ID: <4C59F24B.1010702@zytor.com> (raw)
In-Reply-To: <1280940316-7966-2-git-send-email-bp@amd64.org>
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
next prev parent reply other threads:[~2010-08-04 23:06 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-04 16:45 [PATCH 0/2] Fix 32-bit CPU hotplug issue on AMD Borislav Petkov
2010-08-04 16:45 ` [PATCH 1/2] x86-32: Fix crashes with CPU hotplug on AMD machines Borislav Petkov
2010-08-04 23:05 ` H. Peter Anvin [this message]
2010-08-05 4:48 ` Borislav Petkov
2010-08-05 7:45 ` Roedel, Joerg
2010-08-05 14:14 ` H. Peter Anvin
2010-08-12 14:41 ` Joerg Roedel
2010-08-12 15:34 ` H. Peter Anvin
2010-08-12 15:47 ` Borislav Petkov
2010-08-12 15:47 ` H. Peter Anvin
2010-08-12 17:38 ` Borislav Petkov
2010-08-24 7:33 ` Initial working version (Re: [PATCH 1/2] x86-32: Fix crashes with CPU hotplug on AMD machines) Borislav Petkov
2010-08-29 20:32 ` [PATCH] x86-32, mm: Add an initial page table for core bootstrapping Borislav Petkov
2010-09-02 9:10 ` [PATCH -v1.1] " Borislav Petkov
2010-08-12 17:06 ` [PATCH 1/2] x86-32: Fix crashes with CPU hotplug on AMD machines Joerg Roedel
2010-08-12 19:01 ` H. Peter Anvin
2010-08-12 19:04 ` Joerg Roedel
2010-08-13 12:35 ` Borislav Petkov
2010-08-16 12:19 ` Borislav Petkov
2010-08-16 12:38 ` [PATCH -v2 " Borislav Petkov
2010-08-18 18:41 ` H. Peter Anvin
2010-08-18 19:09 ` Borislav Petkov
2010-08-18 20:55 ` [tip:x86/urgent] x86-32: Fix dummy trampoline-related inline stubs tip-bot for H. Peter Anvin
2010-08-18 20:55 ` [tip:x86/urgent] x86-32: Separate 1:1 pagetables from swapper_pg_dir tip-bot for Joerg Roedel
2010-08-16 12:39 ` [PATCH -v2 2/2] x86, cpu hotplug: Fix cpu bringup concurrency issue Borislav Petkov
2010-08-18 19:03 ` H. Peter Anvin
2010-08-18 19:28 ` Borislav Petkov
2010-08-18 20:04 ` H. Peter Anvin
2010-08-19 18:10 ` [PATCH -v2.1 " Borislav Petkov
2010-08-19 22:58 ` [tip:x86/urgent] x86, hotplug: Serialize CPU hotplug to avoid bringup concurrency issues tip-bot for Borislav Petkov
2010-08-04 16:45 ` [PATCH 2/2] x86, cpu hotplug: Fix cpu bringup concurrency issue Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C59F24B.1010702@zytor.com \
--to=hpa@zytor.com \
--cc=Bhavna.Sarathy@amd.com \
--cc=andreas.herrmann3@amd.com \
--cc=bp@amd64.org \
--cc=conny.seidel@amd.com \
--cc=greg@kroah.com \
--cc=joerg.roedel@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.