qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 2/3] scsi: Enhance scsi_sense_to_errno


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v3 2/3] scsi: Enhance scsi_sense_to_errno
Date: Mon, 21 Aug 2017 13:30:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 21/08/2017 13:11, Fam Zheng wrote:
> On Fri, 08/18 16:36, Paolo Bonzini wrote:
>> On 18/08/2017 16:15, Fam Zheng wrote:
>>> Two changes:
>>>
>>> 1) Look at asc/ascq for NOT_READY and DATA_PROTECT;
>>> 2) Translate SPACE_ALLOC_FAILED as ENOSPC;
>>>
>>> Signed-off-by: Fam Zheng <address@hidden>
>>> ---
>>>  util/scsi.c | 7 +++----
>>>  1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/util/scsi.c b/util/scsi.c
>>> index 92ca436cd0..d42ce33449 100644
>>> --- a/util/scsi.c
>>> +++ b/util/scsi.c
>>> @@ -18,13 +18,11 @@
>>>  int scsi_sense_to_errno(int key, int asc, int ascq)
>>>  {
>>>      switch (key) {
>>> -    case 0x02: /* SCSI_SENSE_NOT_READY */
>>> -        return EBUSY;
>>> -    case 0x07: /* SCSI_SENSE_DATA_PROTECTION */
>>> -        return EACCES;
>>>      case 0x0b: /* SCSI_SENSE_COMMAND_ABORTED */
>>>          return ECANCELED;
>>> +    case 0x02: /* SCSI_SENSE_NOT_READY */
>>>      case 0x05: /* SCSI_SENSE_ILLEGAL_REQUEST */
>>> +    case 0x07: /* SCSI_SENSE_DATA_PROTECTION */
>>>          /* Parse ASCQ */
>>>          break;
>>>      default:
>>
>> UNIT_ATTENTION should also be passed down to the guest without stopping
>> the VM.  Maybe map it to EAGAIN?
> 
> Or just 0?

That works too, it depends on how you define 0.  1h is defined as
informational only and can be dropped, 0x0401 or UNIT_ATTENTION
definitely cannot.

Paolo

>>
>> Looking at what Linux does:
>>
>> - RECOVERED_ERROR should just return 0
>>
>> - 0x0401 is "unit in the process of becoming ready", and it should also
>> be EAGAIN
>>
>> - 0x0402 is "initializing command required", and probably can be fixed
>> by the guest by scsi-block but not by iscsi so it should be its own
>> errno, maybe ENOTCONN?  (iscsi might try sending START STOP UNIT
>> followed by a bunch of TEST UNIT READYs, see scsi_eh_try_stu in Linux's
>> drivers/scsi/scsi_error.c).
> 
> These makes sense to me.
> 
> Fam
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]