From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LOx47-0008VE-DQ
	for qemu-devel@nongnu.org; Mon, 19 Jan 2009 11:33:31 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LOx45-0008U7-Aq
	for qemu-devel@nongnu.org; Mon, 19 Jan 2009 11:33:30 -0500
Received: from [199.232.76.173] (port=47191 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LOx45-0008U3-3c
	for qemu-devel@nongnu.org; Mon, 19 Jan 2009 11:33:29 -0500
Received: from mail-gx0-f15.google.com ([209.85.217.15]:57756)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1LOx44-0004bm-Qu
	for qemu-devel@nongnu.org; Mon, 19 Jan 2009 11:33:28 -0500
Received: by gxk8 with SMTP id 8so67207gxk.10
	for <qemu-devel@nongnu.org>; Mon, 19 Jan 2009 08:33:27 -0800 (PST)
Message-ID: <4974AB48.1070301@codemonkey.ws>
Date: Mon, 19 Jan 2009 10:33:12 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API
References: <1232308399-21679-1-git-send-email-avi@redhat.com>
	<4974943B.4020507@redhat.com> <49749EC5.3080704@codemonkey.ws>
	<200901191618.10082.paul@codesourcery.com>
In-Reply-To: <200901191618.10082.paul@codesourcery.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Paul Brook <paul@codesourcery.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com>

Paul Brook wrote:
> It looks like what you're actually doing is pushing the bounce buffer 
> allocation into the individual packet consumers.
>
> Maybe a solution to this is a 'do IO on IOVEC' actor, with an additional flag 
> that says whether it is acceptable to split the allocation. That way both 
> block and packet interfaces use the same API, and avoids proliferation of 
> manual bounce buffers in packet devices.
>   

I think there may be utility in having packet devices provide the bounce 
buffers, in which case, you could probably unique both into a single 
function with a flag.  But why not just have two separate functions?

Those two functions can live in exec.c too.  The nice thing about using 
map() is that it's easily overriden and chained.  So what I'm proposing.

cpu_physical_memory_map()
cpu_physical_memory_unmap()
do_streaming_IO(map, unmap, ioworker, opaque);
do_packet_IO(map, unmap, buffer, size, ioworker, opaque);

Additional helpers that pass c_p_m_map/unmap would also be acceptable.

Regards,

Anthony Liguori

> Paul
>