Re: [Qemu-ppc] Bug with REPORT LUNS in IBM VSCSI

[Nathan Whitehorn]

On 10/03/13 03:05, Paolo Bonzini wrote:
> Il 02/10/2013 18:05, Nathan Whitehorn ha scritto:
> > > Both Linux and Windows scan each channel separately.  Linux, in
> > > addition, does not expect REPORT LUNS to use the logical unit addressing
> > > method in the returned list of LUNs.  The driver converts the
> > > channel/target/LUN tuple to that addressing method when it builds the
> > > SRP commands.
> > Right, I see that. And this is an approach that works, but is really
> > really ugly since it is assumes a fixed range of possible LUNs. It also
> > relies on some kind of inference about which LUNs actually exist since
> > SRP has no mechanism to report a non-existant "target" back to the host
> > (since there is only one target, it can't have non-existant targets, so
> > there is no mechanism for this).
> I can certainly change REPORT LUNS to report all subtargets, but I need
> to be careful and not break Linux...
>
> Paolo

I wrote this patch this morning. It makes VSCSI report all LUNs when a 
REPORT_LUNS command is addressed to LUN 0 or the well-known "REPORT 
LUNs" LUN (thus satisfying the standard and the FreeBSD driver) and 
gives unchanged behavior for REPORT_LUNS commands addressed to other 
LUNs (thus producing unchanged behavior under Linux and SLOF, which use 
only LUN addressing and so never send anything to LUN 0). If this looks 
reasonable to you, I'll submit it formally to qemu-devel.

The behavior that makes Linux see no changes (reporting sub-LUNs as 
before for REPORT_LUNS addressed to non-zero LUN values) seems to be 
compliant with SPC-4. In particular, following table B.2, the behavior 
of REPORT_LUNS addressed to non-zero non-well-known LUNs is "vendor 
specific", so we can do whatever we like.
-Nathan

vscsi_luns.diff
Description: Text document