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

[Thomas Huth]

 Hi all!

Am Fri, 16 Sep 2011 12:41:40 +0200
schrieb Paolo Bonzini <address@hidden>:

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


I've done some readings about this problem today, and I think I've got
an idea what might be wrong here - seems like a bug in SLOF to me.

First, according to the SLOF source code, it seems to me that its
intention is to to scan target IDs, not channels (but as I haven't
written that part, I am not 100% sure here).

Then I compared how Linux and SLOF fill the 64-bit LUN field in the
SRP_CMD request structure, and they both fill in the target ID at the
same location - but Linux is additionally setting an additional bit in
first byte (see the "lun_from_dev" function in ibmvscsi.c of the
kernel).

Looking at the "SCSI Architecture Model" specification, this additional
bit is used to select the "Logical unit addressing method" instead of
the "Peripheral device addressing method" that SLOF currently uses - and
the "Logical unit addressing method" sounds more reasonable to me when
looking at the places where SLOF tries to fill in the target ID.

So I suggest that I change SLOF to also use the "Logical unit
addressing method" like Linux does, which should result in the fact that
SLOF tries to scan the target IDs instead of the channels/bus IDs.

What do you think, does that sound ok?

 Regards,
  Thomas