Re: [Qemu-devel] virtio scsi host draft specification, v2

[Paolo Bonzini]

On 06/01/2011 04:36 PM, Michael S. Tsirkin wrote:
> Ah, I think I understand now. Both sense and data have in
> fields that might only be used partially?
> In that case I think I agree: it's best to require the use of separate
> buffers for them, in this way used len will give you useful information
> and you won't need sense_len and data_len: just a flag to
> mark the fact that there*is*  a sense buffer following.

If the device wants a sense buffer to be there always, that's sensible. 
 No flag needed here, then.  Also, sense is always "in", there is no out.

But I do not understand how the used len helps me.  If I read the spec 
correctly, the length will be the number of bytes written, but this will 
always point to after the last field.  If sense or data are written 
partially, this will not be written in the fields---in fact, virtio_blk 
does contain both sense_len and residual.  Its sense field is fixed 
size, which is probably why it doesn't contain something like 
datain_size (there is just one variable-size field).

Strictly speaking I wouldn't need dataout_size too, because I have only 
one variable-size read-only field, but I prefer to be future-proof.

I think the following is a good compromise:

1) keep dataout_size, datain_size and sense_size;

2) dataout, datain and sense shall each start a separate buffer, and 
sense shall be contained in a single buffer; it is permissible to put 
sense and the subsequent fields in the same buffer.  This will make it 
easy for the QEMU implementation to pick up its iovecs.

It will also let the device detect mistakes in filling the data sizes. 
In practice I expect 3 descriptors will be used (one direct for 
read-only stuff up to data; one possibly indirect for data; one direct 
for sense and other write-only stuff).

> However some questions:
> 1. I think you don't need numdatain/numdataout: each
> buffer can include in and out segments. Just tell device how many
> buffers are there.

I don't understand.

Paolo