Re: [virtio-comment] Google Comments on Virtio Draft Spec

[Paolo Bonzini <pbonzini@redhat.com>]

Il 06/06/2014 02:59, Andrew Thornton ha scritto:
> > As to cmd_per_lun, you could obey cmd_per_lun and still get TASK SET
> > FULL responses from the target if the host or other guests are using it
> > at the same time.  Perhaps the hypervisor could change that to BUSY
> > (again, not VIRTIO_SCSI_S_BUSY), but this is again a generic SCSI target
> > implementation issue, not specific to virtio-scsi.
>
> If you treat max_sectors and cmd_per_lun as transport-specific limits and
> the INQUIRY data/Block Limits VPDs as SCSI-layer limits, the differences
> become clearer -- for transfer that fail because of limitations from the
> target (INQUIRY/BLOCK LIMITS VPD levels), the target's SCSI-layer response
> is the correct one. For transfers that fail because they hit the transport
> limit (max_sectors/cmd_per_lun), a transport-level response would make more
> sense.

Ok, then that would be the generic VIRTIO_SCSI_S_FAILURE (DID_ERROR).

> > > 2. When a target is hotunplugged with I/O inflight, can we specify which
> > > error response will be returned for the now-terminated I/Os?
>
> > Either I/O is completed, or it is already documented to be ILLEGAL
> > REQUEST/LOGICAL UNIT NOT SUPPORTED.
>
> When an I/O is already running against a target and it is hotremoved,
> ILLEGAL REQUEST/LOGICAL UNIT NOT SUPPORTED is not a correct SCSI response.
> That response would be appropriate if the I/O reached the target after it
> was removed, but not for the case where the command was already running.
>
> Also, consider long-running operations -- once a guest has already seen
> them running on a target (ex: long running operation in progress), it would
> not be correct to return ILLEGAL REQUEST/LOGICAL UNIT NOT SUPPORTED.
>
> We would like to see a transport-layer response here, for example
> VIRTIO_SCSI_S_TRANSPORT_FAILURE. Hot-unplugging a disk is analogous to
> breaking the link to the target and Linux will reflect this as a
> DID_TRANSPORT_DISRUPTED host byte.

I see what you mean.  I agree that VIRTIO_SCSI_S_TRANSPORT_FAILURE is fine.

> 1. REPORT LUNS to the well-known address would work. No device emulation
>    currently supports it to the well-known address, however.
>
> 2. Can we specify that it is not an error (the device will not enter a
>    broken state) to send a command with either an invalid LUN or a command
>    that is too short? (ex: a 1 byte command?). Even an invalid command
>    would serve as a fine no-op, if it doesn't wedge the device.

Hmm, no, I'd be a bit wary of doing that.

Regarding the failure codes, I think they're a fairly obvious match. 
Since there is no "implementation hints" section, I'd rather defer the 
change past 1.0.

I guess we could still do the well-known LUN change if I get a review.

Paolo