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

[Nathan Whitehorn]

On 10/02/13 10:44, Paolo Bonzini wrote:
> Il 02/10/2013 17:33, Nathan Whitehorn ha scritto:
> > On 10/02/13 10:17, Paolo Bonzini wrote:
> > > Il 02/10/2013 17:12, Nathan Whitehorn ha scritto:
> > > > I'm having some trouble with the VSCSI emulation in the pSeries machine.
> > > > It seems that the emulated SCSI target device on the SRP IT_nexus
> > > > properly distributes SCSI commands to its children but does not report
> > > > them in response to a REPORT LUNS request. This happens because it
> > > > forwards REPORT LUNs to target 0 on its child bus instead of answering
> > > > the command itself.
> > > How so?  The SCSI emulation hijacks REPORT_LUNS and does not pass it
> > > down to the device's alloc_req callback, but the request is still
> > > processed as if it came to the device.
> > >
> > > Can you give QEMU's command-line?  Can you reproduce the same bug with
> > > an x86 FreeBSD guest using virtio-scsi?
> > The issue is that VSCSI SRP has only one direct target port and then
> > uses hierarchical LUNs to pass requests further down the bus using the
> > LUN addressing method. My understanding of SAM5 is that the emulated
> > target device should report all of those sub-LUNs, on all sub-targets,
> > in response to a REPORT LUNS command addressed to LUN 0 on the only
> > direct target. Is that correct?
> Interesting.  So you're saying that FreeBSD expects the returned list of
> LUNs to use the logical unit addressing method?

It doesn't expect any particular addressing mode -- the comment was just 
in reference to what QEMU uses (LUN addressing).

I just looked around a little more and found that the Linux in-kernel 
target code also reports all sub-targets:
https://github.com/fajarnugraha/scst/blob/master/ibmvstgt/src/SLES-10-SP3-ibmvscsis.c#L1989
The same definition is in table 285 (section 6.33) of SPC-4, which says 
REPORT LUNs is supposed to report all LUNs accessible from all 
addressing modes in the default report mode.

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

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