public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] CPU hotplug returns CPUs to SAL
Date: Wed, 09 Feb 2005 18:19:43 +0000	[thread overview]
Message-ID: <1107973183.5478.31.camel@tdi> (raw)
In-Reply-To: <1107970828.5478.22.camel@tdi>

Hi Ashok,

   Sorry I missed your patch.  Your assembly is certainly cleaner than
mine.  We seem to have several differences in the state that actually
gets saved and restored though.  For instance, I see you're saving k0,
which is listed as scratch in the spec, but none of the fp, predicate,
branch registers, region registers, or preserved general registers.
Shouldn't a few more of those be preserved under "standard calling
conventions"?  Also, what do you think about treating the saved state as
a stack?  This could eventually allow the BSP to be sent off spinning in
SAL.  Thanks,

	Alex

On Wed, 2005-02-09 at 09:53 -0800, Ashok Raj wrote:
> On Wed, Feb 09, 2005 at 09:40:28AM -0800, Alex Williamson wrote:
> 
> Hi Alex
> 
> In fact i did submit a patch for this about a month ago. I was sharing some
> code from mca side for tlb purge, and this code has been in the swamp for 
> several weeks now. I hope they are settled now, and  i will re submit my 
> patches once again.
> 
> link from old post
> 
> http://marc.theaimsgroup.com/?l=linux-ia64&m\x110239954713260&w=2
> 
> I will repost to match whats there in tony-'s test/release tree asap.
> 
> ashok
> > 
> >        When  a  CPU  is sent offline, it currently goes into a dummy spin
> >    loop
> >    and  pretends  to be gone.  This patch returns the CPU back to SAL via
> >    the
> >    mechanism described in the SAL spec.  The state of secondary CPUs is
> >    saved off to a dynamically allocated stack for use on return to SAL.
> >    I've munged the _start code in head.S to avoid trampling over some of
> >    the preserved registers before we get a chance to save them.  The
> >    assembly could probably use some optimizations, but these are hardly
> >    performance paths.  It seems to work reliably on zx1 and sx1000 boxes,
> >    but needs some exposure on others.  Patch against current bk.  Thanks,
> > 
> >            Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab


  parent reply	other threads:[~2005-02-09 18:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-09 17:40 [PATCH] CPU hotplug returns CPUs to SAL Alex Williamson
2005-02-09 17:53 ` Ashok Raj
2005-02-09 18:19 ` Alex Williamson [this message]
2005-02-09 19:26 ` Ashok Raj
2005-02-09 19:44 ` Alex Williamson
2005-02-09 19:51 ` Luck, Tony
2005-02-09 20:03 ` Alex Williamson
2005-02-09 22:38 ` Ashok Raj
2005-02-09 23:04 ` Alex Williamson
2005-02-09 23:12 ` Ashok Raj
2005-02-11 21:38 ` Ashok Raj

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=1107973183.5478.31.camel@tdi \
    --to=alex.williamson@hp.com \
    --cc=linux-ia64@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox