From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I6sp5-000417-Em for qemu-devel@nongnu.org; Fri, 06 Jul 2007 14:46:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I6sp3-0003y9-Em for qemu-devel@nongnu.org; Fri, 06 Jul 2007 14:46:30 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6sp2-0003xg-Pd for qemu-devel@nongnu.org; Fri, 06 Jul 2007 14:46:28 -0400 Received: from grayson.netsweng.com ([207.235.77.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I6sp2-0002me-Ah for qemu-devel@nongnu.org; Fri, 06 Jul 2007 14:46:28 -0400 Received: from amavis by grayson.netsweng.com with scanned-ok (Exim 3.36 #1 (Debian)) id 1I6sp1-0007yN-00 for ; Fri, 06 Jul 2007 14:46:27 -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 9T1+LWjXoAI5 for ; Fri, 6 Jul 2007 14:46:13 -0400 (EDT) Received: from h150.93.213.151.ip.alltel.net ([151.213.93.150] helo=trantor.stuart.netsweng.com) by grayson.netsweng.com with esmtp (Exim 3.36 #1 (Debian)) id 1I6son-0007y1-00 for ; Fri, 06 Jul 2007 14:46:13 -0400 Date: Fri, 6 Jul 2007 14:45:51 -0400 (EDT) From: Stuart Anderson Subject: Re: [Qemu-devel] [PATCH] linux-user EFAULT implementation In-Reply-To: Message-ID: References: <468E68F7.8070005@bellard.org> 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 Fri, 6 Jul 2007, Stuart Anderson wrote: >> Moreover, I believe using similar functions as Linux for memory access >> (copyfromuser, copytouser, get_user, put_user) would be cleaner. > > This makes sense. That code that I sent was based on the idea that I was > just extending the model that was already there, instead of giving it a > complete overhaul. I'll look into how much work the overhaul would be. After some digging, the one "design-level" issue I have found is that the current lock_user_struct() and the new lock_and_check_user_struct(), interfaces are based on the assumption that we need to map addresses between guest and host, so they provide a place to call g2h() and return the new address. This is different from copy_{to|from}_user(), which assumes all addresses are valid as is, but that the system just needs to ensure they are correctly mapped in for the data copy. Contrary to this, cpu-all.h has the following comment & code: #define GUEST_BASE 0 /* All direct uses of g2h and h2g need to go away for usermode softmmu. */ #define g2h(x) ((void *)((unsigned long)(x) + GUEST_BASE)) #define h2g(x) ((target_ulong)(x - GUEST_BASE)) It appears that g2h() and h2g() are mostly no-ops, with the typecasting being the only possible useful part remaining. So, the question is: Can I simplify this code to assume that guest and host addresses coexist and use the copy_*_user() or just the access_ok() interfaces? This would be one step closer to eliminating the use of g2h() and h2g() in the usermode code as is suggested by the comment in cpu-all.h. One other comment to make, is that in most cases, a simple copy is not sufficient. Unlike the real Linux kernel, in many places, we are doing structure mapping instead of a simple buffer copy. 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