From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LVMRS-00043Q-Np
	for qemu-devel@nongnu.org; Fri, 06 Feb 2009 03:52:06 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LVMRR-00042C-CX
	for qemu-devel@nongnu.org; Fri, 06 Feb 2009 03:52:06 -0500
Received: from [199.232.76.173] (port=48639 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LVMRR-00041z-1K
	for qemu-devel@nongnu.org; Fri, 06 Feb 2009 03:52:05 -0500
Received: from mx2.redhat.com ([66.187.237.31]:54406)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1LVMRQ-00038s-EW
	for qemu-devel@nongnu.org; Fri, 06 Feb 2009 03:52:04 -0500
Message-ID: <498BFA4D.6010107@redhat.com>
Date: Fri, 06 Feb 2009 10:52:29 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <1233826439-16856-1-git-send-email-avi@redhat.com>
	<498B5962.2010202@us.ibm.com>
In-Reply-To: <498B5962.2010202@us.ibm.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: <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: Anthony Liguori <aliguori@us.ibm.com>
Cc: qemu-devel@nongnu.org

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.

This requires that the generic layer be able to tell where a request 
ends; don't know if that's the case now.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.