From patchwork Sat Mar 16 14:10:02 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexey Kardashevskiy X-Patchwork-Id: 228215 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 1B6232C00B7 for ; Sun, 17 Mar 2013 01:09:20 +1100 (EST) Received: from localhost ([::1]:38093 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGrnS-0006g8-94 for incoming@patchwork.ozlabs.org; Sat, 16 Mar 2013 10:09:18 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGrn9-0006dC-EL for qemu-devel@nongnu.org; Sat, 16 Mar 2013 10:09:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UGrn7-0001Uy-EU for qemu-devel@nongnu.org; Sat, 16 Mar 2013 10:08:59 -0400 Received: from mail-pb0-f52.google.com ([209.85.160.52]:56782) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGrn7-0001Ug-8r for qemu-devel@nongnu.org; Sat, 16 Mar 2013 10:08:57 -0400 Received: by mail-pb0-f52.google.com with SMTP id ma3so5032175pbc.11 for ; Sat, 16 Mar 2013 07:08:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=NsinRqNJ3owEzmyK+O8BTT70dg4tiaPiKDqFQ4pDoQg=; b=Z4WM2FNLBs69Y+Vy5QPPWtGpEwXhrczQHVnjvHtd/wNnBuM8S5WH/oL0qdVHqquGTo NZ2x9B+34rMcH1tLvj3SrSwirR5M1qzRDCNIVSSNnjExl0iq/ppwrTUpcNW347A/is+O nY7j0/6YslqjG0eFg9S9T+JwPkz8+45SlKs1No/cZ8W23GWusHmsm5Pohy9E3YnjMlXK rK7eIdLF74UUcNYL9fmAOHtRKxwAJZ62GA9o6OHnQ+lmtapMNpilTaUBtk50xTIlYBUq RlIf5US9VZvaD//PR8Cg8sqnLkIfZb8Sq/FzhCZHUrKjO05eCxsKXGWYzJOQnUAtpL90 WPTQ== X-Received: by 10.66.253.232 with SMTP id ad8mr1514608pad.119.1363442936387; Sat, 16 Mar 2013 07:08:56 -0700 (PDT) Received: from [192.168.1.50] (60-242-102-4.tpgi.com.au. [60.242.102.4]) by mx.google.com with ESMTPS id in5sm13661617pbc.20.2013.03.16.07.08.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Mar 2013 07:08:55 -0700 (PDT) Message-ID: <51447D3A.3080702@ozlabs.ru> Date: Sun, 17 Mar 2013 01:10:02 +1100 From: Alexey Kardashevskiy User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Benjamin Herrenschmidt References: <1363418170-3391-1-git-send-email-aik@ozlabs.ru> <514429B2.4010207@redhat.com> <5144616B.8040808@ozlabs.ru> <1363438887.1244.27.camel@pasglop> In-Reply-To: <1363438887.1244.27.camel@pasglop> X-Gm-Message-State: ALoCoQk+xnipMEabc8sLax+Pi6MrmKTsoVvjNZwBPdmFbnRFVcLEs1Q1VH1qNERzsxaBzEBDnpr4 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.160.52 Cc: Paolo Bonzini , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, David Gibson Subject: Re: [Qemu-devel] [PATCH] scsi-bus: fix endianness bug in store_lun() X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 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 :) dup >r x! r> 8 + ( devarray ndev devcur ) 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 )