From owner-freebsd-ia64@FreeBSD.ORG Thu May 13 15:42:42 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 B725C16A4CE for ; Thu, 13 May 2004 15:42:42 -0700 (PDT) Received: from hermes.sc.intel.com (fmr03.intel.com [143.183.121.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38A2D43D54 for ; Thu, 13 May 2004 15:42:42 -0700 (PDT) (envelope-from arun.sharma@intel.com) Received: from petasus.sc.intel.com (petasus.sc.intel.com [10.3.253.4]) 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i4DMh2rh022571; Thu, 13 May 2004 22:43:02 GMT Received: from unix-os.sc.intel.com (unix-os.sc.intel.com [143.183.96.244]) major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with ESMTP id i4DMhQ8I011077; Thu, 13 May 2004 22:43:26 GMT Received: from intel.com (adsharma-desk.amr.corp.intel.com [143.183.130.155]) by unix-os.sc.intel.com (8.11.6/8.11.2) with ESMTP id i4DMgbF27152; Thu, 13 May 2004 15:42:39 -0700 Message-ID: <40A3F9DD.8080201@intel.com> Date: Thu, 13 May 2004 15:42:37 -0700 From: Arun Sharma User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <40A2A0A2.8040004@intel.com> <20040512232827.GB45389@ns1.xcllnt.net> <40A2D3D7.4030804@intel.com> <20040513053053.GA4487@dhcp01.pn.xcllnt.net> In-Reply-To: <20040513053053.GA4487@dhcp01.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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 22:42:42 -0000 On 5/12/2004 10:30 PM, Marcel Moolenaar wrote: > 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... RSE.BOF is just one of the situations when the OS needs to do an invala. But the SDM vol2 section 4.4.5.3.2 lists three other reasons, one of which happens to be: - Software changes virtual to physical mapping So if you have code that looks like: ld.a r6=[Y] // Stores physical register and a physical address tag in the ALAT ... >> An exception here can change the virtual to physical mapping << st8 [Y]=Z // Doesn't invalidate the ALAT chk.a.clr And the chk incorrectly thinks that the speculation succeeded. Obviously, the above has nothing to do with whether the kernel itself has been compiled with data speculation or not. The possibility I'm looking at is: ld.a r6=[Y] ... st8 [Y]=Z // Clears the ALAT >> external interrupt + kernel data speculation leaving stale ALAT entries << chk.a.clr // Speculation succeeds incorrectly To remedy the first example, the OS needs a invala on entry and for the second situation it needs an invala on exit. -Arun