qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PATCH 01/58] spapr: proper qdevification


From: David Gibson
Subject: Re: [Qemu-ppc] [PATCH 01/58] spapr: proper qdevification
Date: Sat, 17 Sep 2011 00:08:38 +1000
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Sep 16, 2011 at 12:41:40PM +0200, Paolo Bonzini wrote:
> 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.

Um.. I'm confused.  This is a pHyp (aka PowerVM) machine, so there is
no SLOF.  What I'm seeing there seems to contradict the PAPR spec
which is supposed to describe it.  So I don't see how it has a bearing
on SLOF addressing.

> 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?

(2) sounds like what PAPR describes to me, so that sounds fine to me.
But I still don't follow your reasoning leading up to that.

> 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
> 

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson



reply via email to

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