From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LVuXN-0005N7-VG
	for qemu-devel@nongnu.org; Sat, 07 Feb 2009 16:16:30 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LVuXM-0005MA-CD
	for qemu-devel@nongnu.org; Sat, 07 Feb 2009 16:16:29 -0500
Received: from [199.232.76.173] (port=56319 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LVuXM-0005M5-6T
	for qemu-devel@nongnu.org; Sat, 07 Feb 2009 16:16:28 -0500
Received: from mx2.redhat.com ([66.187.237.31]:53172)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1LVuXL-0000Aw-Ql
	for qemu-devel@nongnu.org; Sat, 07 Feb 2009 16:16:28 -0500
Message-ID: <498DFA41.3010202@redhat.com>
Date: Sat, 07 Feb 2009 23:16:49 +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> <498BFA4D.6010107@redhat.com>
	<498C5377.1000202@us.ibm.com>
In-Reply-To: <498C5377.1000202@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:
>>
>> 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.

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 have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.