[Top][All Lists]

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

Re: [Qemu-ppc] [PATCH v2] spapr_vscsi: Fix REPORT_LUNS handling

From: Alexander Graf
Subject: Re: [Qemu-ppc] [PATCH v2] spapr_vscsi: Fix REPORT_LUNS handling
Date: Fri, 21 Feb 2014 13:09:28 +0100

On 20.01.2014, at 16:03, Alexander Graf <address@hidden> wrote:

> On 12.01.2014, at 23:34, Nathan Whitehorn <address@hidden> 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 <address@hidden>
> Thanks, applied to ppc-next.

I've also folded in the patch below in my queue to fix compilation on 32bit 


diff --git a/hw/scsi/spapr_vscsi.c b/hw/scsi/spapr_vscsi.c
index 123a942..a21dd34 100644
--- a/hw/scsi/spapr_vscsi.c
+++ b/hw/scsi/spapr_vscsi.c
@@ -63,7 +63,7 @@
 #define SCSI_SENSE_BUF_SIZE     96

-#define SRP_REPORT_LUNS_WLUN    0xc10100000000000
+#define SRP_REPORT_LUNS_WLUN    0xc10100000000000ULL

 typedef union vscsi_crq {
     struct viosrp_crq s;

reply via email to

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