Date: Wed, 27 Jun 2007 08:44:03 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Christian Kandeler <christian.kandeler@hob.de> Cc: ia64@freebsd.org Subject: Re: Syscalls and RSE Message-ID: <E9C7669A-BAD2-4A13-B5F6-F38CE7FF9132@mac.com> In-Reply-To: <200706271417.02968.christian.kandeler@hob.de> References: <200706211132.32524.christian.kandeler@hob.de> <3700F902-9CC0-4A6A-B625-8E81C12C5D5E@mac.com> <200706271417.02968.christian.kandeler@hob.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 27, 2007, at 5:17 AM, Christian Kandeler wrote: > On Thursday 21 June 2007 19:41, Marcel Moolenaar wrote: > >> When we switch to the kernel stack, we align BSPSTORE to the user >> stack >> (WRT to NaT collections). In other words we preserve the least >> significant 9 bits of BSPSTORE. Since these bits determine when a NaT >> collection will happen and which bit in the RNAT register will >> take the NaT >> bit of the stacked register on a flush, we effectively preserved >> all the NaT >> bits without explicitly saving or restoring anything. > > Yes, I understand that. > >> As such, we never clobber "used" bits in the RNAT register and it >> also >> allows us to flush the dirty registers onto the kernel stack and copy >> them back to user space knowing that any NaT collections on the >> kernel stack >> will be copied to the right location on the user stack. Also, any NaT >> bits left in RNAT after the loadrs on our way out of the kernel >> will be >> those of the user process. > > The problem, I think, is not the RNAT on the way out of the > syscall, but a > collection of undefined NaT bits saved in the kernel and loaded > later in user > space. As I have mentioned in my first mail, this is due to the > fact that we > can advance the saved user space BSPSTORE (and therefore BspLoad > too) over > such a NaT collection in ia64_flush_dirty(). > The reason that this does not usually lead to problems in practice > is probably > that the current Itanium processors set RNAT to zero after a > backing store > switch, so no NaT bits are actually set to 1 by the RSE load that > restores > the undefined NaT collection. This is not guaranteed, of course. > I've tried to verify my theory, and I believe I have succeeded: If > the code in > epc_syscall is correct, then it should tolerate any value in RNAT > after the > backing store switch, since the value of this register is undefined > anyway. > However, when I manually set RNAT to -1 and boot the resulting > kernel, the > system crashes right after entering user space (Illegal Instruction > in the sh > process). I assume this is due to one of the many NaT bits the process > receives after making a system call. I need think about this for a bit. I'll get back to you shortly... -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E9C7669A-BAD2-4A13-B5F6-F38CE7FF9132>