On Fri, Apr 15, 2011 at 3:37 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > On 04/15/2011 04:28 PM, Stefan Hajnoczi wrote: >> Nothing formal. I'm trying to learn SCSI as I go along: >> >> http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=blob;f=include/linux/virtio_scsi.h;hb=refs/heads/tcm_vhost >> >> That's the interface I'm using. Requests are: >> >> [Header][CDB][Data-out buffers*][Data-in buffers*][Footer] >> >> The footer gets filled in with the response. > > My interface is exactly the same as virtio-blk's SCSI passthrough requests: > > ------------------------------ 8<-- ---------------------------- > > Device operation: request queue > ------------------------------- > > The driver queues requests to the virtqueue, and they are used by the device > (not necessarily in order). Each request is of the form > > Requests have the following format: > > struct virtio_scsi_req { > u32 type; > u32 ioprio; > char cmd[]; > char data[][512]; > u8 sense[SCSI_SENSE_BUFFERSIZE]; > u32 sense_len; > u32 residual; > u8 status; > u8 response; > };
The way I approached virtio-scsi was to look at the SCSI Architecture Model document and some of the Linux SCSI code. I'm not sure if letting virtio-blk SCSI pass-through or scsi-generic guide us is a good approach. How do your ioprio and barrier relate to SCSI? There seem to be recent/exotic commands that can have both data-in and data-out buffers. The sense buffer length is also not necessarily 96 bytes max, I believe. I haven't looked into the these two issues but a proper virtio-scsi design should be future proof and include them based on these fancy commands that are being added to SCSI. Stefan