From owner-freebsd-ia64@FreeBSD.ORG Wed May 12 18:48:12 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 229F216A4CE for ; Wed, 12 May 2004 18:48:12 -0700 (PDT) Received: from hermes.sc.intel.com (fmr03.intel.com [143.183.121.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB63843D46 for ; Wed, 12 May 2004 18:48:11 -0700 (PDT) (envelope-from arun.sharma@intel.com) Received: from talaria.sc.intel.com (talaria.sc.intel.com [10.3.253.5]) 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i4D1mVuj000982; Thu, 13 May 2004 01:48:31 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 i4D1mVpk030724; Thu, 13 May 2004 01:48:31 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 i4D1m7F10750; Wed, 12 May 2004 18:48:07 -0700 Message-ID: <40A2D3D7.4030804@intel.com> Date: Wed, 12 May 2004 18:48:07 -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> In-Reply-To: <20040512232827.GB45389@ns1.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 01:48:12 -0000 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. -Arun