Re: [Qemu-devel] [PATCH RFC] virtio: add virtqueue_fill_partial

[Paolo Bonzini]

On 27/04/2015 16:38, Michael S. Tsirkin wrote:
> > "If you never leave holes unwritten in the iov, use virtqueue_fill
> > instead.
> 
> Is it just holes? Never data you are unsure about?

Then "unwritten (or possibly unwritten)"?

If the data you are unsure is at the end, it's okay.  This is what
virtio-scsi does when it has a failure (the "!= VIRTIO_SCSI_S_OK" case).

> >  If the guest is not relying on iov boundaries, it should never
> > be necessary to use this function."
> 
> You never know what guest does though, do you?

I think that this sentence is wrong, but only because you cannot know
the format of _all_ request headers/footers and thus it's wrong to make
such a sweeping generalization.

Anyhow, I'll describe what I had in mind.  Consider the case I gave
before, where you have a 1 sector (512-bytes) read.  Consider now two
guests, both of them passing 2049 bytes for the device-writable area.

Guest 1 doesn't have anylayout; it placed 2048 bytes in iovec 0 and 1
byte in iovec 1.  The device thus has to write bytes 0-511 and byte
2048.  In this case host_len = 2049, guest_len = 512.

Guest 2 has anylayout (or uses virtio v1).  It placed 2048 bytes in
iovec 0 and 1 byte in iovec 1.  The device however "knows" that the read
is just 512 bytes in length; it writes bytes 0-512 (the last byte is the
status) and ignores bytes 513-2048.  In this case host_len = guest_len =
513.

However, there could be a legitimate reason for a device to leave some
bytes uninitialized in the middle, possibly for optimization reasons.
In this case, you might have to use virtqueue_fill_partial.

...

Oh wait, that's exactly what happens with virtio-scsi!

sense_len in the response header is usually zero, and in that case we
don't write the sense[] array.  So, I guess virtio-scsi in the common
case should return just the offset up to sense_len?

Paolo