Understanding XIP, XPSR, XFS registers

Understanding XIP, XPSR, XFS registers

[Keith Owens]

Resuming after MCA/INIT when psr.ic = 1 is relatively easy and it
appears to work with the new MCA/INIT handlers.  Resuming after
MCA/INIT when psr.ic = 0 (i.e. the event occurred in an interrupt
handler) is proving to be a problem.

When MCA/INIT occurs and psr.ic = 0, what is in X{IP,PSR,FS} in PAL
minstate?  Is it the original values of I{IP,PSR,FS}, with I{IP,PSR,FS}
replaced by the values when MCA/INIT was delivered?  Or is I{IP,PSR,FS}
left alone (i.e. they still contain the values delivered to the
interrupt handler), with X{IP,PSR,FS} set to the values when MCA/INIT
was delivered?

Common sense says that I{IP,PSR,FS} is left alone when psr.ic = 0, with
the new values being stored in X{IP,PSR,FS}.  However Intel Itanium
Architecture Software Developer's Manual Volume 2: System Architecture
(24531804.pdf), 11.3.3 Returning to the Interrupted Process, implies
the reverse.

Re: Understanding XIP, XPSR, XFS registers

[Matt Chapman]

My understanding is that X{IP,PSR,FS} contain the old values of
I{IP,PSR,FS}, and I{IP,PSR,FS} contain the real IP,PSR,CFM.
I've always found this counterintuitive too, though it might
simplify the silicon.

Matt


On Fri, Aug 19, 2005 at 05:08:14PM +1000, Keith Owens wrote:
> Resuming after MCA/INIT when psr.ic = 1 is relatively easy and it
> appears to work with the new MCA/INIT handlers.  Resuming after
> MCA/INIT when psr.ic = 0 (i.e. the event occurred in an interrupt
> handler) is proving to be a problem.
> 
> When MCA/INIT occurs and psr.ic = 0, what is in X{IP,PSR,FS} in PAL
> minstate?  Is it the original values of I{IP,PSR,FS}, with I{IP,PSR,FS}
> replaced by the values when MCA/INIT was delivered?  Or is I{IP,PSR,FS}
> left alone (i.e. they still contain the values delivered to the
> interrupt handler), with X{IP,PSR,FS} set to the values when MCA/INIT
> was delivered?
> 
> Common sense says that I{IP,PSR,FS} is left alone when psr.ic = 0, with
> the new values being stored in X{IP,PSR,FS}.  However Intel Itanium
> Architecture Software Developer's Manual Volume 2: System Architecture
> (24531804.pdf), 11.3.3 Returning to the Interrupted Process, implies
> the reverse.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Understanding XIP, XPSR, XFS registers

[david mosberger]

The manual is correct.  You can see that in the (old) MCA backtrace
code where we pick up the state from the X registers if PSR.ic=0.  I
verified at some point that this works as well as it can.

  --david

On 8/19/05, Keith Owens <kaos@sgi.com> wrote:
> Resuming after MCA/INIT when psr.ic = 1 is relatively easy and it
> appears to work with the new MCA/INIT handlers.  Resuming after
> MCA/INIT when psr.ic = 0 (i.e. the event occurred in an interrupt
> handler) is proving to be a problem.
> 
> When MCA/INIT occurs and psr.ic = 0, what is in X{IP,PSR,FS} in PAL
> minstate?  Is it the original values of I{IP,PSR,FS}, with I{IP,PSR,FS}
> replaced by the values when MCA/INIT was delivered?  Or is I{IP,PSR,FS}
> left alone (i.e. they still contain the values delivered to the
> interrupt handler), with X{IP,PSR,FS} set to the values when MCA/INIT
> was delivered?
> 
> Common sense says that I{IP,PSR,FS} is left alone when psr.ic = 0, with
> the new values being stored in X{IP,PSR,FS}.  However Intel Itanium
> Architecture Software Developer's Manual Volume 2: System Architecture
> (24531804.pdf), 11.3.3 Returning to the Interrupted Process, implies
> the reverse.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Mosberger Consulting LLC, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane, Fremont, CA 94536