| Message ID | 1503049022-14749-1-git-send-email-hare@suse.de |
|---|---|
| State | New |
| Headers | show |
Hello Hannes, On 08/18/17 11:37, Hannes Reinecke wrote: > According to SPC-3 INQUIRY and REQUEST SENSE should return GOOD > even on unsupported LUNS. > > Signed-off-by: Hannes Reinecke <hare@suse.com> > --- > hw/scsi/scsi-bus.c | 29 +++++++++++++++++++++++++---- > 1 file changed, 25 insertions(+), 4 deletions(-) > > diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c > index e364410a23..ade31c11f5 100644 > --- a/hw/scsi/scsi-bus.c > +++ b/hw/scsi/scsi-bus.c > @@ -516,8 +516,10 @@ static size_t scsi_sense_len(SCSIRequest *req) > static int32_t scsi_target_send_command(SCSIRequest *req, uint8_t *buf) > { > SCSITargetReq *r = DO_UPCAST(SCSITargetReq, req, req); > + int fixed_sense = (req->cmd.buf[1] & 1) == 0; > > - if (req->lun != 0) { > + if (req->lun != 0 && > + buf[0] != INQUIRY && buf[0] != REQUEST_SENSE) { > scsi_req_build_sense(req, SENSE_CODE(LUN_NOT_SUPPORTED)); > scsi_req_complete(req, CHECK_CONDITION); > return 0; > @@ -535,9 +537,28 @@ static int32_t scsi_target_send_command(SCSIRequest *req, uint8_t *buf) > break; > case REQUEST_SENSE: > scsi_target_alloc_buf(&r->req, scsi_sense_len(req)); > - r->len = scsi_device_get_sense(r->req.dev, r->buf, > - MIN(req->cmd.xfer, r->buf_len), > - (req->cmd.buf[1] & 1) == 0); > + if (req->lun != 0) { > + const struct SCSISense sense = SENSE_CODE(LUN_NOT_SUPPORTED); > + > + if (fixed_sense) { > + r->buf[0] = 0x70; > + r->buf[2] = sense.key; > + r->buf[10] = 10; > + r->buf[12] = sense.asc; > + r->buf[13] = sense.ascq; > + r->len = MIN(req->cmd.xfer, SCSI_SENSE_LEN); > + } else { > + r->buf[0] = 0x72; > + r->buf[1] = sense.key; > + r->buf[2] = sense.asc; > + r->buf[3] = sense.ascq; > + r->len = 8; > + } > + } else { > + r->len = scsi_device_get_sense(r->req.dev, r->buf, > + MIN(req->cmd.xfer, r->buf_len), > + fixed_sense); > + } > if (r->req.dev->sense_is_ua) { > scsi_device_unit_attention_reported(req->dev); > r->req.dev->sense_len = 0; > thank you for the quick patch. I've repeated my original testing steps now, in the following scenarios: edk2:ba40cb31b69d ovmf:ce13d2d8c81f qemu:v2.10.0-rc3 [1] [2] qemu:v2.10.0-rc3+this patch [3] [4] (Edk2 commit ba40cb31b69d was edk2 master just before I pushed my respective edk2 patches, and edk2 commit ce13d2d8c81f is current edk2 master, with my respective patches.) [1] FAIL: as reported originally [2] PASS: my edk2 patches fix ScsiBusDxe (which is justified in itself), and then it deals with QEMU post-ded6ddc5a7b9 [3] PASS: this patch of yours makes the reported symptoms vanish even without applying my patches to edk2 [4] PASS: your patch works fine with the current (fixed) ScsiBusDxe as well, no regressions found. Tested-by: Laszlo Ersek <lersek@redhat.com> If you agree, I'd suggest two additional tags for the commit message: Reported-by: Laszlo Ersek <lersek@redhat.com> Fixes: ded6ddc5a7b95217557fa360913d1213e12d4a6d Thanks! Laszlo
On 19/08/2017 00:55, Laszlo Ersek wrote: > Reported-by: Laszlo Ersek <lersek@redhat.com> > Fixes: ded6ddc5a7b95217557fa360913d1213e12d4a6d And also: Cc: qemu-stable@nongnu.org Thanks to both! Paolo
Quoting Paolo Bonzini (2017-08-22 08:20:23) > On 19/08/2017 00:55, Laszlo Ersek wrote: > > Reported-by: Laszlo Ersek <lersek@redhat.com> > > Fixes: ded6ddc5a7b95217557fa360913d1213e12d4a6d > > And also: > > Cc: qemu-stable@nongnu.org FYI patch freeze for v2.10.1 is Sep 25th. Hannes, were you planning to resend with the suggested commit msg changes? (Or maybe having a willing maintainer add them?) > > > Thanks to both! > > Paolo >
On 15/09/2017 02:21, Michael Roth wrote: > Quoting Paolo Bonzini (2017-08-22 08:20:23) >> On 19/08/2017 00:55, Laszlo Ersek wrote: >>> Reported-by: Laszlo Ersek <lersek@redhat.com> >>> Fixes: ded6ddc5a7b95217557fa360913d1213e12d4a6d >> >> And also: >> >> Cc: qemu-stable@nongnu.org > > FYI patch freeze for v2.10.1 is Sep 25th. Hannes, were you planning to > resend with the suggested commit msg changes? (Or maybe having a willing > maintainer add them?) I'm sending the pull request today or monday. Paolo
diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c index e364410a23..ade31c11f5 100644 --- a/hw/scsi/scsi-bus.c +++ b/hw/scsi/scsi-bus.c @@ -516,8 +516,10 @@ static size_t scsi_sense_len(SCSIRequest *req) static int32_t scsi_target_send_command(SCSIRequest *req, uint8_t *buf) { SCSITargetReq *r = DO_UPCAST(SCSITargetReq, req, req); + int fixed_sense = (req->cmd.buf[1] & 1) == 0; - if (req->lun != 0) { + if (req->lun != 0 && + buf[0] != INQUIRY && buf[0] != REQUEST_SENSE) { scsi_req_build_sense(req, SENSE_CODE(LUN_NOT_SUPPORTED)); scsi_req_complete(req, CHECK_CONDITION); return 0; @@ -535,9 +537,28 @@ static int32_t scsi_target_send_command(SCSIRequest *req, uint8_t *buf) break; case REQUEST_SENSE: scsi_target_alloc_buf(&r->req, scsi_sense_len(req)); - r->len = scsi_device_get_sense(r->req.dev, r->buf, - MIN(req->cmd.xfer, r->buf_len), - (req->cmd.buf[1] & 1) == 0); + if (req->lun != 0) { + const struct SCSISense sense = SENSE_CODE(LUN_NOT_SUPPORTED); + + if (fixed_sense) { + r->buf[0] = 0x70; + r->buf[2] = sense.key; + r->buf[10] = 10; + r->buf[12] = sense.asc; + r->buf[13] = sense.ascq; + r->len = MIN(req->cmd.xfer, SCSI_SENSE_LEN); + } else { + r->buf[0] = 0x72; + r->buf[1] = sense.key; + r->buf[2] = sense.asc; + r->buf[3] = sense.ascq; + r->len = 8; + } + } else { + r->len = scsi_device_get_sense(r->req.dev, r->buf, + MIN(req->cmd.xfer, r->buf_len), + fixed_sense); + } if (r->req.dev->sense_is_ua) { scsi_device_unit_attention_reported(req->dev); r->req.dev->sense_len = 0;
According to SPC-3 INQUIRY and REQUEST SENSE should return GOOD even on unsupported LUNS. Signed-off-by: Hannes Reinecke <hare@suse.com> --- hw/scsi/scsi-bus.c | 29 +++++++++++++++++++++++++---- 1 file changed, 25 insertions(+), 4 deletions(-)