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

[Paolo Bonzini]

On 06/02/2011 01:41 PM, Michael S. Tsirkin wrote:
> Now to our problem:
> As far as I can tell there are two input buffers in each request: sense
> and data. Right?
>
> If sense is fixed length, we can simply put it first, have device write
> sense then data.  This does not seem too limiting, if you want a lot of
> flexibility sense length can be in device config.  If we don't want to
> limit ourselves to fixed length sense, we would have driver use two
> heads for a request.  This is possible but one needs to be careful in
> the driver to make sure there's enough space for both requests. Maybe
> add_bufs API to add multiple bufs might be a good idea here.

I should be on holiday today so I'll answer this quickly.  Sounds like 
we can converge, I'll put data at the end and define the length of sense 
in the config: the device writes a default (defined by the spec to be 
always 96) and the driver can modify it.  The _single_ head would contain:

- read-only: command etc.

followed by:

- write-only: sense, status etc.

followed by:

- read-only: data to device
- write-only: data from device

IIUC, qemu only sees a bunch of read-only and write-only buffers.  It 
doesn't see the relative ordering of read-only vs. write-only.  But it 
knows the sizes of read-only and write-only data, so it can figure out 
datain_size and dataout_size.  sense_size is in the config, so neither 
of the three needs to be in the request.

sense_len needs to stay, since any number of bytes can be written in the 
sense buffer.  The used-length field should be usable for 
uni-directional commands, but I'm not sure about commands that have both 
datain and dataout.  I'll read the SCSI spec about it tomorrow.

Making qemu support arbitrarily partitioned buffers may require some 
extra utility functions to work on iovecs, but nothing too complex.  If 
your patches already contain something like that, please dig them up so 
I can avoid duplicate work!

Paolo