Re: [Qemu-devel] [PATCH v1 1/1] hw/scsi: Report errors and sense to guests through scsi-block

[Paolo Bonzini]

On 02/07/19 08:44, Shinichiro Kawasaki wrote:
> On 7/1/19 8:56 PM, Paolo Bonzini wrote:
>> On 01/07/19 12:14, Shinichiro Kawasaki wrote:
>>> I observe four of them listed below in sense data,
>>> when I ran basic operations to the zoned storage from the guest via 
>>> scsi-block.
>>>
>>>       21h 04h: UNALIGNED WRITE COMMAND
>>>       21h 05h: WRITE BOUNDARY VIOLATION
>>>       21h 06h: ATTEMPT TO READ INVALID DATA
>>>       55h 0Eh: INSUFFICIENT ZONE RESOURCES
>>>
>>> These ASCs can be reported for write or read commands due to unexpected zone
>>> status or write pointer status. Reporting these ASCs to the guest, the user
>>> applications can handle them to manage zone/write pointer status, or help 
>>> the
>>> user application developers to understand the failure reason and fix bugs.
>>>
>>> I took a look in scsi_sense_to_errno() and learned that ASCs are grouped in
>>> errnos. To report the ASCs above to the guest, is it good to add them in 
>>> EINVAL
>>> group defined in scsi_sense_to_errno()? The ASCs are reported with sense key
>>> ILLEGAL_REQUEST or DATA_PROTECT, then I think it fits in the function.
>>
>> The grouping by errno is historical and pretty much broken.  It should
>> be possible to change it to return just a bool.
> 
> The errno grouping of scsi_sense_to_errno() is used not only by scsi-disk but 
> also by block/iscsi for error reporting. Can we avoid errno grouping for 
> iscsi also?

No, but we can do something like

    if (scsi_sense_buf_is_guest_recoverable(r->req.sense,
sizeof(r->req.sense))) {
        /* These errors are handled by guest. */
        sdc->update_sense(&r->req);
        scsi_req_complete(&r->req, *r->status);
        return true;
    }
    error = scsi_sense_buf_to_errno(r->req.sense, sizeof(r->req.sense));

This way there's generally no need to shoehorn ASC codes into errno.  I
still have to test my changes, but I hope to send something within a
couple of days.

Paolo