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

[Alexander Graf]

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 
hosts.


Alex

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_RSP_SENSE_DATA_LEN  18

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

 typedef union vscsi_crq {
     struct viosrp_crq s;