Re: virtio scsi host draft specification, v3

Paolo Bonzini
2011-06-10T14:35:50Z

> If requests are placed on arbitrary queues you'll inevitably run on
> locking issues to ensure strict request ordering.
> I would add here:
>
> If a device uses more than one queue it is the responsibility of the
> device to ensure strict request ordering.

Applied with s/device/guest/g.

> Please do not rely in bus/target/lun here. These are leftovers from
> parallel SCSI and do not have any meaning on modern SCSI
> implementation (eg FC or SAS). Rephrase that to
>
> The lun field is the Logical Unit Number as defined in SAM.

Ok.

> > The status byte is written by the device to be the SCSI status
> > code.
>
> ?? I doubt that exists. Make that:
>
> The status byte is written by the device to be the status code as
> defined in SAM.

Ok.

> > The response byte is written by the device to be one of the
> > following:
> >
> > - VIRTIO_SCSI_S_OK when the request was completed and the
> > status byte
> > is filled with a SCSI status code (not necessarily "GOOD").
> >
> > - VIRTIO_SCSI_S_UNDERRUN if the content of the CDB requires
> > transferring
> > more data than is available in the data buffers.
> >
> > - VIRTIO_SCSI_S_ABORTED if the request was cancelled due to a
> > reset
> > or another task management function.
> >
> > - VIRTIO_SCSI_S_FAILURE for other host or guest error. In
> > particular,
> > if neither dataout nor datain is empty, and the
> > VIRTIO_SCSI_F_INOUT
> > feature has not been negotiated, the request will be
> > immediately
> > returned with a response equal to VIRTIO_SCSI_S_FAILURE.
> >
> And, of course:
>
> VIRTIO_SCSI_S_DISCONNECT if the request could not be processed due
> to a communication failure (eg device was removed or could not be
> reached).

Ok.

> This specification implies a strict one-to-one mapping between host
> and target. IE there is no way of specifying more than one target
> per host.

Actually no, the intention is to use hierarchical LUNs to support
more than one target per host.

Paolo