Date: Wed, 27 Jun 2007 14:17:02 +0200 From: Christian Kandeler <christian.kandeler@hob.de> To: Marcel Moolenaar <xcllnt@mac.com> Cc: ia64@freebsd.org Subject: Re: Syscalls and RSE Message-ID: <200706271417.02968.christian.kandeler@hob.de> In-Reply-To: <3700F902-9CC0-4A6A-B625-8E81C12C5D5E@mac.com> References: <200706211132.32524.christian.kandeler@hob.de> <3700F902-9CC0-4A6A-B625-8E81C12C5D5E@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Regards, Christian Kandeler
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200706271417.02968.christian.kandeler>