WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

Re: [XenPPC] [xenppc-unstable] [POWERPC][XEN] Erratum: Must clear larx/s

To: xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [XenPPC] [xenppc-unstable] [POWERPC][XEN] Erratum: Must clear larx/stcx reservation on exception
From: Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 1 Sep 2006 22:07:09 +0200
Delivery-date: Fri, 01 Sep 2006 13:07:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <E1GJCqh-0004VM-W3@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-ppc-devel-request@lists.xensource.com?subject=help>
List-id: Xen PPC development <xen-ppc-devel.lists.xensource.com>
List-post: <mailto:xen-ppc-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=unsubscribe>
References: <E1GJCqh-0004VM-W3@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ppc-devel-bounces@xxxxxxxxxxxxxxxxxxx
[POWERPC][XEN] Erratum: Must clear larx/stcx reservation on exception

PowerPC 970 Erratum that an "OS should execute a stcx in
the interrupt handler to clear the reservation."

Where do you see this erratum?  I can't find it in any 970
errata sheet.  Furthermore, it's not a CPU bug at all; every
PowerPC on the planet works this way, it's part of the
architecture.  See the "Interrupt Processing" chapter in Book III.

     stw r0, UREGS_cr(r1)            /* save CR */
     mfspr r0, SPRN_HSPRG1
     std r0, UREGS_r13(r1)           /* save R13 from HSPRG1 */
+
+ /* Blow away any reservation according to 970 errata after saving CR */
+    stdcx. r1, 0, r1

I hope it's okay to blow away not only the reservation, but also
the data that's at the memory address in GPR1, because there's
nothing preventing this store-conditional from succeeding AFAICS
(if the CPU happens to have a reservation there -- yeah quite
unlikely, but is it impossible?)


Segher


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel

<Prev in Thread] Current Thread [Next in Thread>