[Top][All Lists]

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

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

From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [PATCH] scsi-bus: fix endianness bug in store_lun()
Date: Sat, 16 Mar 2013 23:11:23 +1100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130107 Thunderbird/17.0.2

On 16/03/13 19:13, Paolo Bonzini wrote:
Il 16/03/2013 08:16, Alexey Kardashevskiy ha scritto:
SCSI protocol is defined as big endian. The SCSI command REPORT_LUNS
returns the list of LUNs, 8 bytes each.

The store_lun() function is called from scsi_target_emulate_report_luns()
to fill the LUNs list which is sent later to a guest a response. However
it puts the 2 bytes long big-endian value while it is 8 bytes long.

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?

What bug are you trying to fix?

It is a ppc64 system firmware/bios (aka SLOF) which expects 8 bytes big
endian value and therefore cannot boot from SCSI devices with LUN!=0.
I can fix QEMU or SLOF but not sure which one.


The patch fixes it. Tested on PPC64 platform.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
  hw/scsi-bus.c |    6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index a97f1cd..7059dc2 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -310,11 +310,11 @@ struct SCSITargetReq {
  static void store_lun(uint8_t *outbuf, int lun)
      if (lun < 256) {
-        outbuf[1] = lun;
+        outbuf[7] = lun;
-    outbuf[1] = (lun & 255);
-    outbuf[0] = (lun >> 8) | 0x40;
+    outbuf[7] = (lun & 255);
+    outbuf[6] = (lun >> 8) | 0x40;

  static bool scsi_target_emulate_report_luns(SCSITargetReq *r)


reply via email to

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