From owner-freebsd-ia64@FreeBSD.ORG Thu May 13 17:23:46 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 41F7C16A4CE for ; Thu, 13 May 2004 17:23:46 -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 B339F43D2F for ; Thu, 13 May 2004 17:23:45 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i4E0NjXe050740; Thu, 13 May 2004 17:23:45 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.11/8.12.11/Submit) id i4E0Njxw050739; Thu, 13 May 2004 17:23:45 -0700 (PDT) (envelope-from marcel) Date: Thu, 13 May 2004 17:23:45 -0700 From: Marcel Moolenaar To: Arun Sharma Message-ID: <20040514002345.GA50681@ns1.xcllnt.net> References: <40A2A0A2.8040004@intel.com> <20040512232827.GB45389@ns1.xcllnt.net> <40A2D3D7.4030804@intel.com> <20040513053053.GA4487@dhcp01.pn.xcllnt.net> <40A3F9DD.8080201@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40A3F9DD.8080201@intel.com> User-Agent: Mutt/1.5.5.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: Fri, 14 May 2004 00:23:46 -0000 On Thu, May 13, 2004 at 03:42:37PM -0700, Arun Sharma wrote: > > 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 Sure, but that needs to be handled in the PMAP layer. You don't really want to invalidate the ALAT just in case a VM mapping might change. In practice I don't expect this to happen other than when the process has been swapped out before and is now being swapped in. > 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. I agree that we need to pay attention to it, but I'd like to have a more detailed analysis before we add invala instructions. I feel that invalidating the ALAT on entry into the kernel and on exit from the kernel is too much of a pessimization. I can easily be wrong... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net