From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1I8MaW-0004s7-3a
	for qemu-devel@nongnu.org; Tue, 10 Jul 2007 16:45:36 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1I8MaT-0004rr-UL
	for qemu-devel@nongnu.org; Tue, 10 Jul 2007 16:45:35 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1I8MaT-0004ro-OZ
	for qemu-devel@nongnu.org; Tue, 10 Jul 2007 16:45:33 -0400
Received: from sp604003mt.neufgp.fr ([84.96.92.56] helo=smTp.neuf.fr)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <fabrice@bellard.org>) id 1I8MaT-000509-8P
	for qemu-devel@nongnu.org; Tue, 10 Jul 2007 16:45:33 -0400
Received: from [84.99.204.144] by sp604003mt.gpm.neuf.ld
	(Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006))
	with ESMTP id <0JKZ00DRVDNUD2Y1@sp604003mt.gpm.neuf.ld> for
	qemu-devel@nongnu.org; Tue, 10 Jul 2007 22:45:31 +0200 (CEST)
Date: Tue, 10 Jul 2007 22:45:16 +0200
From: Fabrice Bellard <fabrice@bellard.org>
Subject: Re: [Qemu-devel] [PATCH] linux-user EFAULT implementation
In-reply-to: <200707101338.44885.paul@codesourcery.com>
Message-id: <4693EFDC.3080604@bellard.org>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <Pine.LNX.4.64.0707061111150.12799@trantor.stuart.netsweng.com>
	<4692A55D.5050102@bellard.org>
	<Pine.LNX.4.64.0707092218270.12799@trantor.stuart.netsweng.com>
	<200707101338.44885.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Paul Brook wrote:
(...]
> Using g2h directly is bad. g2h is an implementation detail of one particular 
> memory model.
> 
> The whole point of the lock_user abstraction (or a similar copy_from_user 
> abstraction) is that almost none of the code cares how "user" memory is 
> accessed. One of the long-term goals of this abstraction is to allow the 
> softmmu code to be used with userspace emulation. In this case a region may 
> be split across multiple discontiguous host pages.

I confirm that I expected g2h() to be completely removed in case the 
Linux user access API is used.

> The reason I used a locking paradigm rather than a copying one is that it 
> allows a zero-copy implementation in the common case. I've no strong 
> objections to a copying interface, however it must be implementation 
> agnostic.

Since you agree for the copying interface, I suggest to convert all the 
code to it. The exact implementation of access_ok(), copy_to_user(), 
copy_from_user()... will be easily modifiable if one day softmmu user 
mode is needed.

In the only specific case of potentially big unbounded memory areas 
(such as read/write buffers), a different API must be used where it is 
possible to get a pointer to user pages (e.g. ptr = lock_user_page(addr, 
rw_mode); if (!ptr) return -EFAULT; unlock_user_page(ptr)), so that no 
copy is performed while being able to handle any user page remapping.

Regards,

Fabrice.