From owner-freebsd-ia64@FreeBSD.ORG Wed Jun 27 15:44:34 2007 Return-Path: X-Original-To: ia64@freebsd.org Delivered-To: freebsd-ia64@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6659F16A421 for ; Wed, 27 Jun 2007 15:44:34 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.174]) by mx1.freebsd.org (Postfix) with ESMTP id 3A16413C4B0 for ; Wed, 27 Jun 2007 15:44:34 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/smtpout04/MantshX 4.0) with ESMTP id l5RFiY28002731; Wed, 27 Jun 2007 08:44:34 -0700 (PDT) Received: from [172.16.1.4] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id l5RFiV6d005490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2007 08:44:32 -0700 (PDT) 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> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 27 Jun 2007 08:44:03 -0700 To: Christian Kandeler X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: ia64@freebsd.org Subject: Re: Syscalls and RSE X-BeenThere: freebsd-ia64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the IA-64 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2007 15:44:34 -0000 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