From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPDfW-0000Ze-Dz for qemu-devel@nongnu.org; Tue, 20 Jan 2009 05:17:14 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPDfV-0000ZA-O4 for qemu-devel@nongnu.org; Tue, 20 Jan 2009 05:17:13 -0500 Received: from [199.232.76.173] (port=35548 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPDfV-0000Z4-9i for qemu-devel@nongnu.org; Tue, 20 Jan 2009 05:17:13 -0500 Received: from mx2.redhat.com ([66.187.237.31]:51939) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPDfU-0002sc-Tp for qemu-devel@nongnu.org; Tue, 20 Jan 2009 05:17:13 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0KAHCkn005050 for ; Tue, 20 Jan 2009 05:17:12 -0500 Message-ID: <4975A4A6.6000207@redhat.com> Date: Tue, 20 Jan 2009 12:17:10 +0200 From: Avi Kivity 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> <1232308399-21679-2-git-send-email-avi@redhat.com> <18804.34053.211615.181730@mariner.uk.xensource.com> <4974943B.4020507@redhat.com> <49749EC5.3080704@codemonkey.ws> <18804.45277.255939.338648@mariner.uk.xensource.com> <4974D34D.9070300@codemonkey.ws> In-Reply-To: <4974D34D.9070300@codemonkey.ws> 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: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori wrote: > > Scenario 2 (callbacks) > 0) Register minimum required bounce memory at init time > 1) Register callback and begin data mapping > 2) Succeed in mapping first part of packet and 1 page of bounced buffer > 3) Bounce buffer is exhausted, callback will not be invoked until the > next unmap > 4) Deadlock > > You could add some sort of call to determine if the bounce memory is > exhausted and try to take some corrective action in #2 but it gets ugly. > > So as I said earlier, I think the callback model makes sense when you > have streaming data (where there are no packet boundaries). I think > it's pretty difficult to avoid deadlocking though with callbacks in a > packet model (where boundaries must be preserved). > If you specify the boundaries (an additional input array, or maybe a function that says whether a particular point is a "good enough" boundary) then I think it can be workable. -- error compiling committee.c: too many arguments to function