[Qemu-devel] [PATCH] scsi-block: Add qdev error properties

Fam Zheng posted 1 patch 6 years, 8 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20170817102848.19294-1-famz@redhat.com
Test FreeBSD passed
Test checkpatch passed
Test docker passed
Test s390x passed
There is a newer version of this series
hw/scsi/scsi-disk.c | 1 +
1 file changed, 1 insertion(+)
[Qemu-devel] [PATCH] scsi-block: Add qdev error properties
Posted by Fam Zheng 6 years, 8 months ago
This makes the werror/rerror options available on the scsi-block device,
to allow user specify error handling policy in the same way as scsi-hd
etc.

Signed-off-by: Fam Zheng <famz@redhat.com>
---
 hw/scsi/scsi-disk.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index 5f1e5e8070..27d917f7c3 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -2972,6 +2972,7 @@ static const TypeInfo scsi_cd_info = {
 
 #ifdef __linux__
 static Property scsi_block_properties[] = {
+    DEFINE_BLOCK_ERROR_PROPERTIES(SCSIDiskState, qdev.conf),         \
     DEFINE_PROP_DRIVE("drive", SCSIDiskState, qdev.conf.blk),
     DEFINE_PROP_END_OF_LIST(),
 };
-- 
2.13.4


Re: [Qemu-devel] [PATCH] scsi-block: Add qdev error properties
Posted by Paolo Bonzini 6 years, 8 months ago
On 17/08/2017 12:28, Fam Zheng wrote:
> This makes the werror/rerror options available on the scsi-block device,
> to allow user specify error handling policy in the same way as scsi-hd
> etc.
> 
> Signed-off-by: Fam Zheng <famz@redhat.com>

I'm not sure this is enough, because you would only obey the
rerror/werror action if ioctl fails, not if the ioctl succeeds but the
command fails (the "r->status && *r->status" conditional in
scsi_disk_req_check_error).

Paolo

> ---
>  hw/scsi/scsi-disk.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> index 5f1e5e8070..27d917f7c3 100644
> --- a/hw/scsi/scsi-disk.c
> +++ b/hw/scsi/scsi-disk.c
> @@ -2972,6 +2972,7 @@ static const TypeInfo scsi_cd_info = {
>  
>  #ifdef __linux__
>  static Property scsi_block_properties[] = {
> +    DEFINE_BLOCK_ERROR_PROPERTIES(SCSIDiskState, qdev.conf),         \
>      DEFINE_PROP_DRIVE("drive", SCSIDiskState, qdev.conf.blk),
>      DEFINE_PROP_END_OF_LIST(),
>  };
> 


Re: [Qemu-devel] [PATCH] scsi-block: Add qdev error properties
Posted by Fam Zheng 6 years, 8 months ago
On Thu, 08/17 13:44, Paolo Bonzini wrote:
> On 17/08/2017 12:28, Fam Zheng wrote:
> > This makes the werror/rerror options available on the scsi-block device,
> > to allow user specify error handling policy in the same way as scsi-hd
> > etc.
> > 
> > Signed-off-by: Fam Zheng <famz@redhat.com>
> 
> I'm not sure this is enough, because you would only obey the
> rerror/werror action if ioctl fails, not if the ioctl succeeds but the
> command fails (the "r->status && *r->status" conditional in
> scsi_disk_req_check_error).

Yes, I missed that.  Why isn't scsi_handle_rw_error called in that if block
currently?

Fam

Re: [Qemu-devel] [PATCH] scsi-block: Add qdev error properties
Posted by Paolo Bonzini 6 years, 8 months ago
On 17/08/2017 14:03, Fam Zheng wrote:
> On Thu, 08/17 13:44, Paolo Bonzini wrote:
>> On 17/08/2017 12:28, Fam Zheng wrote:
>>> This makes the werror/rerror options available on the scsi-block device,
>>> to allow user specify error handling policy in the same way as scsi-hd
>>> etc.
>>>
>>> Signed-off-by: Fam Zheng <famz@redhat.com>
>>
>> I'm not sure this is enough, because you would only obey the
>> rerror/werror action if ioctl fails, not if the ioctl succeeds but the
>> command fails (the "r->status && *r->status" conditional in
>> scsi_disk_req_check_error).
> 
> Yes, I missed that.  Why isn't scsi_handle_rw_error called in that if block
> currently?

A recursive answer is because scsi-block doesn't have rerror and werror
(and it's the only one that sets r->status, see scsi_block_dma_command).

More precisely, scsi_handle_rw_error more or less assumes error != 0
(see the switch statement and blk_error_action), so some other changes
are needed to cover that case---at least not overwrite the sense and
ensure something sensible comes out of the QMP event.

Paolo