From: Glauber Costa <gcosta@redhat.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
tglx@linutronix.de, mingo@elte.hu, hugh@veritas.com
Subject: Re: [PATCH 03/15] x86: remove early_gdt_descr reference
Date: Mon, 09 Jun 2008 12:49:45 -0300 [thread overview]
Message-ID: <484D5119.5020206@redhat.com> (raw)
In-Reply-To: <1213024983.3508.28.camel@localhost.localdomain>
James Bottomley wrote:
> On Mon, 2008-06-09 at 11:16 -0300, Glauber Costa wrote:
>> since we use switch_to_new_gdt, there is no point
>> in assigning early_gdt_descr except for the first
>> assignment, which is done manually.
>
> What makes you think you can do this? If you don't update the early
> boot gdt, they all end up using the Boot CPU one. The problem with this
> is that there's a time from start_secondary to switch_to_new_gdt where
> the per cpu selector (%fs) and the pda selector (%gs) are those of the
> boot CPU. The former isn't a problem but the CPU number is in the
> latter, and it's used in that path before we get to the initialisation.
You are right, I missed it.
However, it only seem to be used in cpu_init, and very early. Sure there
are some users _before_ we load the new gdt, but nothing prevents them
to be moved after it. (Of course, this patch is wrong anyway).
And if we do that, we can even take the %fs loading out of head_32.S
Of course, it's only valid if those are indeed the only early users of it.
Is there any other use I'm missing?
next prev parent reply other threads:[~2008-06-09 15:54 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-09 14:16 [PATCH 0/15] Improve x86 smpboot integration Glauber Costa
2008-06-09 14:16 ` [PATCH 01/15] x86: use stack_start in x86_64 Glauber Costa
2008-06-09 14:16 ` [PATCH 02/15] x86: don't use gdt_page openly Glauber Costa
2008-06-09 14:16 ` [PATCH 03/15] x86: remove early_gdt_descr reference Glauber Costa
2008-06-09 14:16 ` [PATCH 04/15] x86: move x86_64 gdt closer to i386 Glauber Costa
2008-06-09 14:16 ` [PATCH 05/15] x86: use initial_code for i386 Glauber Costa
2008-06-09 14:16 ` [PATCH 06/15] x86: boot secondary cpus through initial_code Glauber Costa
2008-06-09 14:16 ` [PATCH 07/15] x86: clearing io_apic harmless for x86_64 Glauber Costa
2008-06-09 14:16 ` [PATCH 08/15] x86: remove ifdef from stepping Glauber Costa
2008-06-09 14:16 ` [PATCH 09/15] x86: change __setup_vector_irq with setup_vector_irq Glauber Costa
2008-06-09 14:16 ` [PATCH 10/15] x86: provide connect_bsp_APIC for x86_64 Glauber Costa
2008-06-09 14:16 ` [PATCH 11/15] x86: move enabling of io_apic to prepare_cpus Glauber Costa
2008-06-09 14:16 ` [PATCH 12/15] x86: change naming to match x86_64 Glauber Costa
2008-06-09 14:16 ` [PATCH 13/15] x86: remove cpu from maps Glauber Costa
2008-06-09 14:16 ` [PATCH 14/15] x86: move cpu_exit_clear to process_32.c Glauber Costa
2008-06-09 14:16 ` [PATCH 15/15] x86: take load_sp0 out of smpboot.c Glauber Costa
2008-06-09 15:23 ` [PATCH 11/15] x86: move enabling of io_apic to prepare_cpus Maciej W. Rozycki
2008-06-09 15:52 ` Glauber Costa
2008-06-09 19:44 ` Glauber Costa
2008-06-09 20:12 ` Maciej W. Rozycki
2008-06-09 20:53 ` Yinghai Lu
2008-06-09 21:00 ` Maciej W. Rozycki
2008-06-10 2:46 ` Maciej W. Rozycki
2008-06-10 5:08 ` Yinghai Lu
2008-06-10 13:00 ` Glauber Costa
2008-06-10 13:30 ` Maciej W. Rozycki
2008-06-10 19:09 ` Yinghai Lu
2008-06-10 19:36 ` Maciej W. Rozycki
2008-06-10 19:49 ` Yinghai Lu
2008-06-11 0:29 ` Maciej W. Rozycki
2008-06-11 2:32 ` Yinghai Lu
2008-06-11 12:57 ` Maciej W. Rozycki
2008-06-09 21:02 ` Glauber Costa
2008-06-09 15:23 ` [PATCH 03/15] x86: remove early_gdt_descr reference James Bottomley
2008-06-09 15:49 ` Glauber Costa [this message]
2008-06-09 17:20 ` James Bottomley
2008-06-09 17:23 ` Glauber Costa
2008-06-09 17:40 ` James Bottomley
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=484D5119.5020206@redhat.com \
--to=gcosta@redhat.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox