Date: Thu, 13 May 2004 15:42:37 -0700 From: Arun Sharma <arun.sharma@intel.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-ia64@freebsd.org Subject: Re: invala Message-ID: <40A3F9DD.8080201@intel.com> In-Reply-To: <20040513053053.GA4487@dhcp01.pn.xcllnt.net> References: <40A2A0A2.8040004@intel.com> <20040512232827.GB45389@ns1.xcllnt.net> <40A2D3D7.4030804@intel.com> <20040513053053.GA4487@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40A3F9DD.8080201>