public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@suse.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	Linus Torvalds <torvalds@transmeta.com>,
	davidm@hpl.hp.com, ralf@gnu.org, paulus@samba.org,
	anton@samba.org, schwidefsky@de.ibm.com, ak@suse.de,
	davem@redhat.com
Subject: Re: [PATCH] 2.5.25 Hotplug CPU boot changes
Date: Mon, 15 Jul 2002 17:23:22 +0200	[thread overview]
Message-ID: <20020715172322.B13036@suse.de> (raw)
In-Reply-To: <1026736141.13885.105.camel@irongate.swansea.linux.org.uk>

On Mon, Jul 15, 2002 at 01:29:01PM +0100, Alan Cox wrote:

 > Q: What prevents a CPU coming up -during- an MTRR change once the rest
 > of the cpu hot plugging is present ?

"The force". The more I think about mtrr.c and hotplug, the more I
regret having eaten lunch today.  I'm not convinced it will do the right
thing at all with hotplug. init_secondary_cpu() does no frobbing of
the MSRs. For this we relied upon that IPI from cpu #0, which we never
saw. Ugh. horrid.

So possible issues are..

1. cpu #0 sets MSRs, then sets off an IPI. cpu #n isn't 'plugged' yet,
   so we miss the IPI and new processors don't get the MSRs poked,
   but get their 'state' set so it appears to be ok, but isn't.
2. init on secondary cpu's probably needs to wait until the boot CPU mtrr
   code is in a 'known safe' state before it does the magickal
   'sync based on whats in cpu #0'
3. What happens when cpu #0 has finished poking registers, and then sets
   off an IPI to resync the others, when cpu #n hasn't gotten as far in the
   boot sequence to handle that IPI correctly yet ?

        Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

  reply	other threads:[~2002-07-15 15:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-15  8:58 [PATCH] 2.5.25 Hotplug CPU boot changes Rusty Russell
2002-07-15 12:29 ` Alan Cox
2002-07-15 15:23   ` Dave Jones [this message]
2002-07-16  0:48   ` Rusty Russell

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=20020715172322.B13036@suse.de \
    --to=davej@suse.de \
    --cc=ak@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=anton@samba.org \
    --cc=davem@redhat.com \
    --cc=davidm@hpl.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=ralf@gnu.org \
    --cc=rusty@rustcorp.com.au \
    --cc=schwidefsky@de.ibm.com \
    --cc=torvalds@transmeta.com \
    /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