qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 0/4] Block DMA helpers (v2)


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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]