From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LVwwr-00044w-8h for qemu-devel@nongnu.org; Sat, 07 Feb 2009 18:50:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LVwwp-00044d-Fp for qemu-devel@nongnu.org; Sat, 07 Feb 2009 18:50:56 -0500 Received: from [199.232.76.173] (port=33164 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LVwwp-00044Y-AB for qemu-devel@nongnu.org; Sat, 07 Feb 2009 18:50:55 -0500 Received: from e34.co.us.ibm.com ([32.97.110.152]:47454) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LVwwo-0002FB-Ng for qemu-devel@nongnu.org; Sat, 07 Feb 2009 18:50:54 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n17NnIPM004586 for ; Sat, 7 Feb 2009 16:49:18 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n17Nooju213688 for ; Sat, 7 Feb 2009 16:50:50 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n17NonfK005098 for ; Sat, 7 Feb 2009 16:50:49 -0700 Message-ID: <498E1E45.3000307@us.ibm.com> Date: Sat, 07 Feb 2009 17:50:29 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1233826439-16856-1-git-send-email-avi@redhat.com> <498B5962.2010202@us.ibm.com> <498BFA4D.6010107@redhat.com> <498C5377.1000202@us.ibm.com> <498DFA41.3010202@redhat.com> In-Reply-To: <498DFA41.3010202@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/4] Block DMA helpers (v2) Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org Avi Kivity wrote: > Anthony Liguori wrote: >>> >>> This requires that the generic layer be able to tell where a request >>> ends; don't know if that's the case now. >> >> Maybe create a sub QEMUSGList from another QEMUSGList. The other >> option is passing an offset and size to anything that takes a >> QEMUSGList. You could potentially get smart with how sub SG lists >> were managed by making them just store an internal offset/size. >> Although things start to get overly complex at some stage. > > Lifetime issues will kill us. I note that something resembling this > sort of cleverness is holding up copyless networking -- different > parts of an skb have different lifetimes. Yup. > But I thought of something simpler: have virtio call virtio-* to > inquire whether a ring entry terminates a request. This would also > simplify the virtio device emulations somewhat. I don't know that I follow what you mean by "terminates a request". I'm not sure I know what problem you're talking about solving. Regards, Anthony Liguori