From owner-freebsd-ia64@FreeBSD.ORG Fri Jun 29 16:42:46 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 EB1A816A46C for ; Fri, 29 Jun 2007 16:42:46 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.172]) by mx1.freebsd.org (Postfix) with ESMTP id BD7B813C45A for ; Fri, 29 Jun 2007 16:42:46 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/smtpout02/MantshX 4.0) with ESMTP id l5TGgjvq028743; Fri, 29 Jun 2007 09:42:46 -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 l5TGgf56006994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Jun 2007 09:42:42 -0700 (PDT) In-Reply-To: <200706290948.04330.christian.kandeler@hob.de> References: <200706211132.32524.christian.kandeler@hob.de> <200706271417.02968.christian.kandeler@hob.de> <200706290948.04330.christian.kandeler@hob.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23365936-A0DB-48FF-A051-2E18816FC742@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 29 Jun 2007 09:42:12 -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: Fri, 29 Jun 2007 16:42:47 -0000 On Jun 29, 2007, at 12:48 AM, Christian Kandeler wrote: >> The problem is in the assumption that ar.rnat is still valid after >> writing to ar.bspstore. The SDM states that ar.rnat is undefined. >> I haven't seen any indication that ar.rnat is anything other than >> what it was before, but that's probably because without speculation >> it's always 0 anyway :-) >> The fact a bogus ar.rnat value affects a process simply means that >> we in fact propagate the ar.rnat back to the process after a flush. >> This is a good thing! > > Huh? But we don't "propagate back" anything - we manipulate the NaT > collection. The process gets back a random collection of NaT bits > instead of the one that it had before doing the syscall. > It's not the process' fault that the backing store is switched in the > kernel, so it must not be affected by it. > And I don't understand how the process crashing is a good thing: -1 is > a completely legal value for RNAT to have after the switch, so the > process will crash on any hardware whose implementation of > "undefined" is "all bits set to 1". You misunderstand the point I was trying to make. While it's not a good thing to clobber the ar.rnat register, it's a good thing that clobbering it causes the process to fail for it means that exit out of the kernel through the epc_syscall code path will indeed restore the ar.rnat register that was clobbered on entry. It simply means that the kernel exit is correct. That's a good thing. Yes, it's not a good thing that kernel entry isn't, but we know it's only the entry that's broken and not also the exit. >> However, the question is: should we write the saved ar.rnat value >> back to ar.rnat after the backing store switch? Doing so will make >> the assumption that ar.rnat is preserved after a backing store >> switch valid (in a programmatic manner). >> >> Would this address the problem you describe or did I misunderstand? > > The way I see it, the code right now either > a) wrongly assumes RNAT is preserved by the backing store switch or > b) wrongly assumes RNAT does not need to be preserved. Both. If A then B :-) -- Marcel Moolenaar xcllnt@mac.com