From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LVSOM-000725-UW for qemu-devel@nongnu.org; Fri, 06 Feb 2009 10:13:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LVSOM-00071V-8R for qemu-devel@nongnu.org; Fri, 06 Feb 2009 10:13:18 -0500 Received: from [199.232.76.173] (port=41804 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LVSOM-00071P-3N for qemu-devel@nongnu.org; Fri, 06 Feb 2009 10:13:18 -0500 Received: from e2.ny.us.ibm.com ([32.97.182.142]:32901) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LVSOL-0007J5-EX for qemu-devel@nongnu.org; Fri, 06 Feb 2009 10:13:17 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n16FBLZG022841 for ; Fri, 6 Feb 2009 10:11:21 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n16FDERw177382 for ; Fri, 6 Feb 2009 10:13:14 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n16FDEZt006352 for ; Fri, 6 Feb 2009 10:13:14 -0500 Message-ID: <498C5377.1000202@us.ibm.com> Date: Fri, 06 Feb 2009 09:12:55 -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> In-Reply-To: <498BFA4D.6010107@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: >> BTW, what are your plans for virtio? > > To hope someone else does it. > >> I'd reckon that just trying to map the full SG list and failing >> gracefully if unable would be sufficient. You could also convert the >> element to contain a QEMUSGList and then make use of the IO helpers >> in virtio-blk and virtio-net. It just gets a little funky for >> simpler things like virtio-console and virtio-balloon. > > One way is to convert the generic transport layer to use two > QEMUSGLists (one for incoming, one for outgoing) and leave it at > that. virtio-blk could use the block dma helpers, virtio-net could do > something else, and we'd add a qemu_sglist_to_buffer(sg, offset, len, > buf) and qemu_sglist_from_buffer(sg, offset, len, buf) to allow > low-bandwidth easy access to virtio data. Yeah, that's probably the best way of doing it. > > 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. Regards, Anthony Liguori