Re: [Qemu-devel] [PATCH] scsi-bus: fix endianness bug in store_lun()

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 17/03/13 00:01, Benjamin Herrenschmidt wrote:
> On Sat, 2013-03-16 at 23:11 +1100, Alexey Kardashevskiy wrote:
>>> No, LUNs are composed of four 2-byte big-endian values.
>>
>> I cannot find it in "SCSI Commands References Manual"
>> (for example here -
>> http://www.seagate.com/staticfiles/support/disc/manuals/Interface%
>> 20manuals/100293068c.pdf
>> ). It just says that it is 8 bytes per
>> LUN and SCSI itself is big endian. Could you please point me to
>> the correct spec?
>
> The confusion comes from the old SCSI protocol LUN as a 2 bytes number
> identifying a unit for a given bus/device and the "new style" LUN as a
> more generic concept such as used in SRP (ie vscsi is SRP) which
> encompass the bus, ID and LUN in one big number.

> The actual type of LUN returned by REPORT_LUN depends on the
> SELECT_REPORT field (I don't remember the details, but the doco you
> point to say to see what's in SAM-4) and the result is *variable* in
> size, so it should be kosher for qemu to just return 2 bytes as long as
> the LUN_LIST_LENGTH field of the reply is correct.

No, it is always 8 bytes long. Does not say anywhere that it can be of 
another size.

> So it all needs a bit of double checking but I wouldn't be surprised if
> at the end of the day the culprit was my SLOF code :-)


The patch below fixes the issue on the SLOF side. Your job? :)
So, I revert the QEMU patch then and will post this. I just
wonder if other 6 bytes are used (or can be used) anyhow by someone
but I need to find SAM-5 spec first, does not seem very easy :-/

btw why was it x@ but not x@-be? I mean yes, is it the same on ppc
but would help a lot in reading this write-only language :)


diff --git a/board-qemu/slof/vio-vscsi.fs b/board-qemu/slof/vio-vscsi.fs
index 8a150ea..88d4085 100644
--- a/board-qemu/slof/vio-vscsi.fs
+++ b/board-qemu/slof/vio-vscsi.fs
@@ -606,7 +606,7 @@ CREATE sector d# 512 allot
          dup rot 0 fill                ( devarray devcur ndev lunarray 
size mem )
          dup >r swap move r>           ( devarray devcur ndev mem )
          dup sector l@ 3 >> 0 DO       ( devarray devcur ndev mem memcur )
-           dup dup x@ j 8 << 8000 or or 30 << swap x! 8 +
+           dup dup w@-be j 8 << 8000 or or 30 << swap x! 8 +
          LOOP drop
         rot                           ( devarray ndev mem devcur )
          dup >r x! r> 8 +              ( devarray ndev devcur )



-- 
Alexey