Re: [Qemu-devel] [RFC PATCH] implement vmware pvscsi device

[Stefan Hajnoczi]

On Fri, Apr 15, 2011 at 3:37 PM, Paolo Bonzini <address@hidden> 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