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;
--
2.12.0
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
© 2016 - 2026 Red Hat, Inc.