qemu-devel.nongnu.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).