[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] Google Comments on Virtio Draft Spec
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