All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Whitehorn <nwhitehorn@freebsd.org>
To: qemu-devel@nongnu.org
Cc: pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH] spapr_vscsi: Fix REPORT_LUNS handling
Date: Mon, 02 Dec 2013 11:51:18 -0600	[thread overview]
Message-ID: <529CC896.5020304@freebsd.org> (raw)
In-Reply-To: <1382099622-87967-1-git-send-email-nwhitehorn@freebsd.org>

Any news on this? FreeBSD is unbootable from CDROM devices in 
QEMU/pseries without this patch.
-Nathan

On 10/18/13 07:33, Nathan Whitehorn wrote:
> Intercept REPORT_LUNS commands addressed either to SRP LUN 0 or the well-known
> LUN for REPORT_LUNS commands. This is required to implement the SAM and SPC
> specifications.
>
> Since SRP implements only a single SCSI target port per connection, the SRP
> target is required to report all available LUNs in response to a REPORT_LUNS
> command addressed either to LUN 0 or the well-known LUN. Instead, QEMU was
> forwarding such requests to the first QEMU SCSI target, with the result that
> initiators that relied on this feature would only see LUNs on the first QEMU
> SCSI target.
>
> Behavior for REPORT_LUNS commands addressed to any other LUN is not specified
> by the standard and so is left unchanged. This preserves behavior under Linux
> and SLOF, which enumerate possible LUNs by hand and so address no commands
> either to LUN 0 or the well-known REPORT_LUNS LUN.
>
> Signed-off-by: Nathan Whitehorn <nwhitehorn@freebsd.org>
> ---
>   hw/scsi/spapr_vscsi.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 57 insertions(+)
>
> diff --git a/hw/scsi/spapr_vscsi.c b/hw/scsi/spapr_vscsi.c
> index 2a26042..87e0fb3 100644
> --- a/hw/scsi/spapr_vscsi.c
> +++ b/hw/scsi/spapr_vscsi.c
> @@ -63,6 +63,8 @@
>   #define SCSI_SENSE_BUF_SIZE     96
>   #define SRP_RSP_SENSE_DATA_LEN  18
>   
> +#define SRP_REPORT_LUNS_WLUN    0xc10100000000000
> +
>   typedef union vscsi_crq {
>       struct viosrp_crq s;
>       uint8_t raw[16];
> @@ -720,12 +722,67 @@ static void vscsi_inquiry_no_target(VSCSIState *s, vscsi_req *req)
>       }
>   }
>   
> +static void vscsi_report_luns(VSCSIState *s, vscsi_req *req)
> +{
> +    BusChild *kid;
> +    int i, len, n, rc;
> +    uint8_t *resp_data;
> +    bool found_lun0;
> +
> +    n = 0;
> +    found_lun0 = false;
> +    QTAILQ_FOREACH(kid, &s->bus.qbus.children, sibling) {
> +        SCSIDevice *dev = SCSI_DEVICE(kid->child);
> +
> +        n += 8;
> +        if (dev->channel == 0 && dev->id == 0 && dev->lun == 0)
> +            found_lun0 = true;
> +    }
> +    if (!found_lun0) {
> +        n += 8;
> +    }
> +    len = n+8;
> +
> +    resp_data = malloc(len);
> +    memset(resp_data, 0, len);
> +    stl_be_p(resp_data, n);
> +    i = found_lun0 ? 8 : 16;
> +    QTAILQ_FOREACH(kid, &s->bus.qbus.children, sibling) {
> +        DeviceState *qdev = kid->child;
> +        SCSIDevice *dev = SCSI_DEVICE(qdev);
> +
> +        if (dev->id == 0 && dev->channel == 0)
> +            resp_data[i] = 0;
> +        else
> +            resp_data[i] = (2 << 6);
> +        resp_data[i] |= dev->id;
> +        resp_data[i+1] = (dev->channel << 5);
> +        resp_data[i+1] |= dev->lun;
> +        i += 8;
> +    }
> +
> +    vscsi_preprocess_desc(req);
> +    rc = vscsi_srp_transfer_data(s, req, 0, resp_data, len);
> +    free(resp_data);
> +    if (rc < 0) {
> +        vscsi_makeup_sense(s, req, HARDWARE_ERROR, 0, 0);
> +        vscsi_send_rsp(s, req, CHECK_CONDITION, 0, 0);
> +    } else {
> +        vscsi_send_rsp(s, req, 0, len - rc, 0);
> +    }
> +}
> +
>   static int vscsi_queue_cmd(VSCSIState *s, vscsi_req *req)
>   {
>       union srp_iu *srp = &req->iu.srp;
>       SCSIDevice *sdev;
>       int n, lun;
>   
> +    if ((srp->cmd.lun == 0 || be64_to_cpu(srp->cmd.lun) == SRP_REPORT_LUNS_WLUN)      && srp->cmd.cdb[0] == REPORT_LUNS) {
> +        vscsi_report_luns(s, req);
> +        return 0;
> +    }
> +
>       sdev = vscsi_device_find(&s->bus, be64_to_cpu(srp->cmd.lun), &lun);
>       if (!sdev) {
>           DPRINTF("VSCSI: Command for lun %08" PRIx64 " with no drive\n",

  reply	other threads:[~2013-12-02 17:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-18 12:33 [Qemu-devel] [PATCH] spapr_vscsi: Fix REPORT_LUNS handling Nathan Whitehorn
2013-12-02 17:51 ` Nathan Whitehorn [this message]
2013-12-02 17:58   ` Paolo Bonzini
2014-01-02 15:05     ` Nathan Whitehorn
2014-01-02 15:31 ` Alexander Graf
2014-01-02 15:41   ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2014-01-02 15:56     ` ronnie sahlberg
2014-01-02 18:14       ` Nathan Whitehorn
2014-01-02 21:44         ` Paolo Bonzini
2014-01-02 18:23     ` Nathan Whitehorn
2014-01-03 13:27       ` Paolo Bonzini
2014-01-12 22:35         ` Nathan Whitehorn
2014-01-02 18:28   ` [Qemu-devel] " Nathan Whitehorn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=529CC896.5020304@freebsd.org \
    --to=nwhitehorn@freebsd.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.