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

[Anthony Liguori <aliguori@us.ibm.com>]

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