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

[Alexey Kardashevskiy]

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 address@hidden 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 address@hidden 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