On 20.01.2014, at 16:03, Alexander Graf <[email protected]> wrote:
>
> On 12.01.2014, at 23:34, Nathan Whitehorn <[email protected]> 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 <[email protected]>
>
> 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;
