From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Vrg-000676-SG for qemu-devel@nongnu.org; Fri, 16 Sep 2011 06:41:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4Vrf-0006Tz-SN for qemu-devel@nongnu.org; Fri, 16 Sep 2011 06:41:48 -0400 Message-ID: <4E7327E4.7040708@redhat.com> Date: Fri, 16 Sep 2011 12:41:40 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1315989802-18753-1-git-send-email-agraf@suse.de> <1315989802-18753-2-git-send-email-agraf@suse.de> <20110915031437.GR9025@yookeroo.fritz.box> <4E71A2D2.2080008@redhat.com> <20110916030616.GZ9025@yookeroo.fritz.box> In-Reply-To: <20110916030616.GZ9025@yookeroo.fritz.box> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/58] spapr: proper qdevification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , qemu-devel Developers , qemu-ppc@nongnu.org, David Gibson On 09/16/2011 05:06 AM, David Gibson wrote: >> > >> > 1) do you mean, in Linux terms, one target per SCSI _host_ or one >> > target per SCSI _channel_? i.e. if you looks at >> > /sys/bus/scsi/devices, right now it looks like >> > >> > 0:0:0:0 0:0:1:0 (two targets on the same host and channel) >> > >> > Should it be? >> > >> > 0:0:0:0 0:1:0:0 (one target per channel) >> > >> > or >> > >> > 0:0:0:0 1:0:0:0 (one target per host) >> > >> > If it is the former, then you are simply hitting a limitation of the >> > SCSI layer in QEMU and I do have patches to make assignment more >> > flexible. Based on the Linux VSCSI driver, and based on what SLOF >> > does, I'd guess that's what you mean. > > Well, now I'm confused. I had a look at a pHyp machine, and Linux > seemed to see it as multiple targets on a single channel, but I'm sure > the PAPR spec says you shouldn't have that. So I'm going to have to > look closer now. If this is the case, there might be a bug in SLOF's probing of SCSI devices. SLOF probes target 0/LUN 0 on eight channels, i.e. from 0:0:0 to 7:0:0. Linux however shows them the same as pHyp, i.e. from 0:0:0 to 0:7:0. The reason this works is because LUN parsing in QEMU is completely broken (by Ben's admission in spapr_vscsi.c :)) and so SLOF's x:0:0 and Linux's 0:x:0 end up referring to the same device. Now, when implementing SCSI addressing I had two choices: (1) leave them where Linux sees them. This seems correct according to your experiments with pHyp, but then SLOF could only see 0:0:0; (2) move the devices so that both SLOF and Linux see them as x:0:0 (one target per channel). This would be inconsistent with pHyp, but it doesn't break either SLOF or Linux. So, I would like to agree on a plan for merging the SCSI addressing series. Right now I am doing (2), because it lets me use the current version of SLOF. Is it okay for you to merge the feature with these semantics? If you want to change to (1), that can be done easily. However, it requires fixing SLOF, so it would have to go preferably through Alex's PPC tree. (Again, that would be just the defaults---the addressing can always be overridden by using -device explicitly). Paolo