From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LWDwQ-0007tn-Ao for qemu-devel@nongnu.org; Sun, 08 Feb 2009 12:59:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LWDwN-0007sn-TU for qemu-devel@nongnu.org; Sun, 08 Feb 2009 12:59:37 -0500 Received: from [199.232.76.173] (port=33239 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LWDwN-0007se-FL for qemu-devel@nongnu.org; Sun, 08 Feb 2009 12:59:35 -0500 Received: from e3.ny.us.ibm.com ([32.97.182.143]:57432) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LWDwN-0008JE-14 for qemu-devel@nongnu.org; Sun, 08 Feb 2009 12:59:35 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n18HvR6d028735 for ; Sun, 8 Feb 2009 12:57:27 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n18HxV8R104974 for ; Sun, 8 Feb 2009 12:59:31 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n18HwRJh004975 for ; Sun, 8 Feb 2009 12:58:27 -0500 Message-ID: <498F1D6E.3070106@us.ibm.com> Date: Sun, 08 Feb 2009 11:59:10 -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> <498E1E45.3000307@us.ibm.com> <498EA648.4030502@redhat.com> In-Reply-To: <498EA648.4030502@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: >>> 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". > > A request is composed of multiple virtio ring elements. The last ring > entry for a given request terminates it. > >> I'm not sure I know what problem you're talking about solving. > > The Linux guest interface is at the request level, accepting > scatter/gather lists as parameters. Correct. More accurately, it is: int (*add_buf)(struct virtqueue *vq, struct scatterlist sg[], unsigned int out_num, unsigned int in_num, void *data); > The qemu host interface is at the ring element level, leaving the > task of gathering ring elements to make a request (and gathering > segments to make a scatter/gather list) to users. I don't think that's totally accurate. Where the host and guest interface differ is that instead of having the symmetric version of this, namely: vdev->buf_added(vq, sg, out_num, in_num, data); Which then would require some sort of: put_buf(vq, data, len) We have a virtqueue_pop(elem) where elem contains all of the information passed to add_buf. We have a virtqueue_push() function that's analogous to the above put_buf() and then we have a separate virtio_notify() function which would be the symmetric form of kick(). The names are different but the basic functions are the same. Other than the difference of having split sg lists and using a structure, I don't see how they are different. > > I think we should make the qemu virtio host interface talk at the > request level, rather than the ring entry level. If we do that, we'll > get a cleaner, easier to use interface. Can you give an example? I'm having a hard time seeing what you mean. > But I think I know what you're getting at: virtio sglists contain a > descriptor followed by data. We could handle that by adding > > qemu_sglist_sublist(QEMUSGList *sg, QEMUSGList *sublist, > target_phys_addr_t offset, target_phys_addr_t len); > > it would involve extra copying and allocation, but we could live with > it, I think. Yup. Regards, Anthony Liguori