From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IY4nL-0001eo-4E for qemu-devel@nongnu.org; Wed, 19 Sep 2007 15:01:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IY4nK-0001eU-9X for qemu-devel@nongnu.org; Wed, 19 Sep 2007 15:01:06 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IY4nK-0001eH-1o for qemu-devel@nongnu.org; Wed, 19 Sep 2007 15:01:06 -0400 Received: from grayson.netsweng.com ([207.235.77.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IY4nJ-0008N8-Im for qemu-devel@nongnu.org; Wed, 19 Sep 2007 15:01:05 -0400 Received: from amavis by grayson.netsweng.com with scanned-ok (Exim 3.36 #1 (Debian)) id 1IY4nJ-0001tY-00 for ; Wed, 19 Sep 2007 15:01:05 -0400 Received: from grayson.netsweng.com ([127.0.0.1]) by localhost (grayson.netsweng.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg6WoK4z3b6R for ; Wed, 19 Sep 2007 15:00:44 -0400 (EDT) Received: from h134.99.28.71.ip.alltel.net ([71.28.99.134] helo=trantor.stuart.netsweng.com) by grayson.netsweng.com with esmtp (Exim 3.36 #1 (Debian)) id 1IY4my-0001r8-00 for ; Wed, 19 Sep 2007 15:00:44 -0400 Date: Wed, 19 Sep 2007 15:00:18 -0400 (EDT) From: Stuart Anderson Subject: Re: [Qemu-devel] RFC: [0/11] EFAULT patch In-Reply-To: <1190167518.14938.348.camel@rapid> Message-ID: References: <1190167518.14938.348.camel@rapid> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Wed, 19 Sep 2007, J. Mayer wrote: > Then, the changes you've done, changing long arguments (which should be > target_long to be correct, you can take a look at the last patch I sent > on the list) to pointers, for example in function prototypes, are > incorrect. I just went, and looked at the linux code again for 32 on 64 for x86_64 and powerpc. In both of these cases (and I suspect the others as well), the parameters which are passed via registers are 0 extended from 32 bits to 64 bit in the syscall entry asm code. This way, once the C code is called via the sys_call_table, everything is dealt with as 64 bits. This actually keeps the rest of the code simpler as the rest of the kernel doesn't have to be extending & truncating pointers everywhere else. On x86_64 and powerpc, it appears that both user (ie target) and kernel pointers co-exist and that the code that maps structures assume that the __get_user()/__put_user() and copy_*_user() routines can handle any special situation. The pointers passed into functions like cp_compat_stat() are 64-bits for both the structure located in the kernel, and the one located in user space. My understanding is that we want to do as the kernel does as much as possible. In light of this, wouldn't we want to be decreasing the use of target_long where pointers may be involved instead of increasing it? Stuart Stuart R. Anderson anderson@netsweng.com Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149