[PATCH 0/2] scsi: to fix issue on passing host_status to the guest kernel

[PATCH 0/2] scsi: to fix issue on passing host_status to the guest kernel

[Dongli Zhang]

This patchset fixes the issue on passing 'host_status' to the guest kernel.

The 1st patch fixes the erroneous usage of req->host_status.

The 2nd patch is to pass the SCSI_HOST_ERROR to the guest kernel when the
req->bus->info->fail() is not implemented. I do not add 'Fixes:' because I
am not sure if to not pass SCSI_HOST_ERROR was on purpose, especially for
security reason.

Thank you very much!

Dongli Zhang

[PATCH 1/2] scsi/scsi_bus: use host_status as parameter for scsi_sense_from_host_status()

[Dongli Zhang]

The scsi_sense_from_host_status() always returns GOOD since
req->host_status is 255 (-1) at this time. Change req->host_status to
host_status so that scsi_sense_from_host_status() will be able to return
the expected value.

Fixes: f3126d65b393("scsi: move host_status handling into SCSI drivers")
Cc: Joe Jin <joe.jin@oracle.com>
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
 hw/scsi/scsi-bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
index 77325d8cc7..d46650bd8c 100644
--- a/hw/scsi/scsi-bus.c
+++ b/hw/scsi/scsi-bus.c
@@ -1465,7 +1465,7 @@ void scsi_req_complete_failed(SCSIRequest *req, int host_status)
     assert(req->ops != &reqops_unit_attention);
 
     if (!req->bus->info->fail) {
-        status = scsi_sense_from_host_status(req->host_status, &sense);
+        status = scsi_sense_from_host_status(host_status, &sense);
         if (status == CHECK_CONDITION) {
             scsi_req_build_sense(req, sense);
         }
-- 
2.17.1

[PATCH 2/2] scsi/utils: pass host_status = SCSI_HOST_ERROR to guest kernel

[Dongli Zhang]

For scsi_req_complete_failed() and when the req->bus->info->fail() is
implemented, the virtio-scsi passes SCSI_HOST_ERROR to the guest kernel as
VIRTIO_SCSI_S_FAILURE, while the pvscsi passes SCSI_HOST_ERROR to guest
kernel as BTSTAT_HASOFTWARE.

However, the scsi_req_complete_failed()->scsi_sense_from_host_status()
always returns GOOD for SCSI_HOST_ERROR, when the req->bus->info->fail() is
not implemented (e.g., megasas). As a result, the sense is not passed to
the guest kernel.

The SCSI_HOST_ERROR is reproduced on purpose by below QEMU command line:

-device megasas,id=vscsi0,bus=pci.0,addr=0x4 \
-drive file=/dev/sdc,format=raw,if=none,id=drive01 \
-device scsi-block,bus=vscsi0.0,channel=0,scsi-id=0,lun=0,drive=drive01 \

... and when we remove the /dev/sdc from the host with:

"echo 1 > /sys/block/sdc/device/delete"

This patch passes sense_code_IO_ERROR to the guest kernel for
host_status = SCSI_HOST_ERROR.

(This issue is detected by running a testing code from Rui Loura).

Cc: Joe Jin <joe.jin@oracle.com>
Cc: Adnan Misherfi <adnan.misherfi@oracle.com>
Cc: Rui Loura <rui.loura@oracle.com>
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
 scsi/utils.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scsi/utils.c b/scsi/utils.c
index 357b036671..086a1fea66 100644
--- a/scsi/utils.c
+++ b/scsi/utils.c
@@ -638,6 +638,9 @@ int scsi_sense_from_host_status(uint8_t host_status,
     case SCSI_HOST_ABORTED:
         *sense = SENSE_CODE(COMMAND_ABORTED);
         return CHECK_CONDITION;
+    case SCSI_HOST_ERROR:
+        *sense = SENSE_CODE(IO_ERROR);
+        return CHECK_CONDITION;
     case SCSI_HOST_RESET:
         *sense = SENSE_CODE(RESET);
         return CHECK_CONDITION;
-- 
2.17.1

Re: [PATCH 0/2] scsi: to fix issue on passing host_status to the guest kernel

[Dongli Zhang]

ping?

Thank you very much!

Dongli Zhang

On 12/10/21 6:16 AM, Dongli Zhang wrote:
> This patchset fixes the issue on passing 'host_status' to the guest kernel.
> 
> The 1st patch fixes the erroneous usage of req->host_status.
> 
> The 2nd patch is to pass the SCSI_HOST_ERROR to the guest kernel when the
> req->bus->info->fail() is not implemented. I do not add 'Fixes:' because I
> am not sure if to not pass SCSI_HOST_ERROR was on purpose, especially for
> security reason.
> 
> Thank you very much!
> 
> Dongli Zhang
> 
> 
>