qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] scsi-bus: fix to allow some special SCSI com


From: TAMUKI Shoichi
Subject: Re: [Qemu-devel] [PATCH v2] scsi-bus: fix to allow some special SCSI commands
Date: Wed, 16 Jul 2014 06:20:03 +0900

Hello,

From: Paolo Bonzini <address@hidden>
Subject: Re: [PATCH v2] scsi-bus: fix to allow some special SCSI commands
Date: Tue, 15 Jul 2014 19:05:25 +0200

> > Currently, some special SCSI commands sent from the initiator in a
> > guest do not reach the target device.  To avoid this, extended (0x7e,)
> > variable length (0x7f,) and vendor specific (0xc0..0xff) opcodes are
> > now treated as valid CDBs.
> > 
> > Originally, the most significant 3 bits of a SCSI opcode specified the
> > length of the CDB.  However, when variable-length CDBs were created,
> > this correspondence was changed, and the entire opcode must be
> > examined to determine the CDB length.  The CDBs with the opcodes above
> > are done that way for now.
> > 
> > Signed-off-by: TAMUKI Shoichi <address@hidden>
> > ---
> > v2: add a new argument to scsi_req_new(), and modify all invocations
> > in hw/{scsi,usb}, since this function is not called only for virtio-
> > scsi.
> 
> I think that for scsi-generic it is harmless to pass extra bytes at the
> end of the CDB, and QEMU right now does not support more than 16 bytes
> for the CDB (see SCSI_CMD_BUF_SIZE in include/hw/scsi/scsi.h).
> 
> Assuming 16-byte commands are enough, does this patch work for you?
> 
> diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
> index 4341754..51e4f37 100644
> --- a/hw/scsi/scsi-bus.c
> +++ b/hw/scsi/scsi-bus.c
> @@ -1194,6 +1194,9 @@
>       case 2:
>           cmd->len = 10;
>           break;
> +    case 3:
> +        cmd->len = SCSI_CMD_BUF_SIZE;
> +        break;
>       case 4:
>           cmd->len = 16;
>           break;

Yes, it is ok for me since I currently care neither 0x7e extended
opcode nor 0x7f variable length opcode.

> You will probably also need to pass the transfer length and direction
> down from the device model to scsi-generic.c.  Effectively you will be
> ignoring cmd->xfer and cmd->mode if the host device can provide them if
> the first byte in the cdb identifies a vendor-specific command.  You can
> add a callback to SCSIBusInfo, and call it from scsi_req_parse; for
> virtio-scsi the callback could look something like this:
> 
> int virtio_scsi_parse_req(SCSICommand *cmd, void *hba_private)
> {
>      VirtIOSCSIReq *req = hba_private;
> 
>      cmd->xfer = req->qsgl.size;
>      if (cmd->xfer == 0) {
>          cmd->mode = SCSI_XFER_NONE;
>      } else if (iov_size(req->elem._sg, req->elem.in_num)
>                 > req->resp_size)) {
>          cmd->mode = SCSI_XFER_FROM_DEV;
>      } else {
>          cmd->mode = SCSI_XFER_TO_DEV;
>      }
> }

Thank you for pointing that out.

> I'll try to prepare a complete patch tomorrow, but I would like to
> understand your actual requirements for the CDB length.

I am very glad to hear that.  My actual requirement is to pass vendor-
specific commands and their CDB length is less than 16 bytes.

Thanks for your cooperation.

Regards,
TAMUKI Shoichi



reply via email to

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