From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LOwpK-0004Nd-I1 for qemu-devel@nongnu.org; Mon, 19 Jan 2009 11:18:14 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LOwpK-0004NJ-1e for qemu-devel@nongnu.org; Mon, 19 Jan 2009 11:18:14 -0500 Received: from [199.232.76.173] (port=35717 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LOwpJ-0004ND-P2 for qemu-devel@nongnu.org; Mon, 19 Jan 2009 11:18:13 -0500 Received: from mx20.gnu.org ([199.232.41.8]:51006) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LOwpJ-0003O6-GB for qemu-devel@nongnu.org; Mon, 19 Jan 2009 11:18:13 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LOwpI-00065Z-Cs for qemu-devel@nongnu.org; Mon, 19 Jan 2009 11:18:12 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API Date: Mon, 19 Jan 2009 16:18:08 +0000 References: <1232308399-21679-1-git-send-email-avi@redhat.com> <4974943B.4020507@redhat.com> <49749EC5.3080704@codemonkey.ws> In-Reply-To: <49749EC5.3080704@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200901191618.10082.paul@codesourcery.com> 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 Cc: Ian Jackson , Avi Kivity >[block iterator] > I agree that this model could be formalized into something that took a > 'do IO on (data, len)' actor. In fact, since map() and unmap() are > pretty generic, they too could be actors. This would then work for CPU > memory IO, PCI memory IO, etc. > > The packet IO API is a bit different. It looks like: >... > if (offset < len) { > =A0 =A0sg[0].iov_base =3D alloc_buffer(size); > =A0 =A0cpu_physical_memory_rw(sg[0].iov_base, size); > > In this case, it isn't useful to get a callback with some of the packet > data. You need to know up front whether you can map all of the packet > data. In fact, a callback API doesn't really work because it implies > that at the end of the callback, you either release the data or that the > next callback could not be invoked until you unmap a previous data. It looks like what you're actually doing is pushing the bounce buffer=20 allocation into the individual packet consumers. Maybe a solution to this is a 'do IO on IOVEC' actor, with an additional fl= ag=20 that says whether it is acceptable to split the allocation. That way both=20 block and packet interfaces use the same API, and avoids proliferation of=20 manual bounce buffers in packet devices. Paul