|
From: | Avi Kivity |
Subject: | [Qemu-devel] Re: [PATCH 0/4] Block DMA helpers (v2) |
Date: | Sun, 08 Feb 2009 20:04:17 +0200 |
User-agent: | Thunderbird 2.0.0.19 (X11/20090105) |
Anthony Liguori wrote:
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.
You're right - I didn't dig deep enough. We could replace struct iovec in_sg[VIRTQUEUE_MAX_SIZE]; struct iovec out_sg[VIRTQUEUE_MAX_SIZE];by QEMUSGList, which would be a minor improvement, but I thought things were very different for some reason.
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.
An example would be how the code is structured now (as opposed to how I thought it was structured).
-- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |