From owner-freebsd-ia64@FreeBSD.ORG Wed May 12 22:30:54 2004 Return-Path: Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1C6716A4CE for ; Wed, 12 May 2004 22:30:54 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47EC243D2F for ; Wed, 12 May 2004 22:30:54 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i4D5UspQ046390; Wed, 12 May 2004 22:30:54 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) i4D5Urft004642; Wed, 12 May 2004 22:30:53 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i4D5UrtM004641; Wed, 12 May 2004 22:30:53 -0700 (PDT) (envelope-from marcel) Date: Wed, 12 May 2004 22:30:53 -0700 From: Marcel Moolenaar To: Arun Sharma Message-ID: <20040513053053.GA4487@dhcp01.pn.xcllnt.net> References: <40A2A0A2.8040004@intel.com> <20040512232827.GB45389@ns1.xcllnt.net> <40A2D3D7.4030804@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40A2D3D7.4030804@intel.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-ia64@freebsd.org Subject: Re: invala X-BeenThere: freebsd-ia64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the IA-64 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2004 05:30:54 -0000 On Wed, May 12, 2004 at 06:48:07PM -0700, Arun Sharma wrote: > On 5/12/2004 4:28 PM, Marcel Moolenaar wrote: > > >On Wed, May 12, 2004 at 03:09:38PM -0700, Arun Sharma wrote: > >> > >>I noticed that the code in exception.S:TRAP() doesn't invalidate the ALAT > >>on a register backing store switch. This could be a problem if the kernel > >>starts using data speculation (say by using a different compiler). > >>However, restorectx is doing the right thing by using invala. > > > >Why would this be a problem? > > The kernel data speculation might introduce entries into the ALAT which > might cause the user data speculation to think that the speculation > (advanced load) succeeded, when in fact it has failed. True. But doesn't a rfi instruction restore RSE.BOF, and thus preserve the virtual to physical register mapping? Note also that we have the EPC syscall path (sys/ia64/ia64/syscall.S), where we also switch stacks, but we do not have the rfi on our way out. This could mean that we actually do need an invala in that case. I do not know under which conditions RSE.BOF is preserved... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net