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

[Nathan Whitehorn]

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?

Instead, the SPAPR VSCSI layer just relays all commands based on the LUN 
field to the target derived from the LUN (see vscsi_device_find() in 
spapr_vscsi.c). The effect is that if you send a REPORT LUNS command, it 
only ends up on QEMU target 0, despite the fact that the entire QEMU 
SCSI bus is a logical child of target 0 on the SRP bus, and thus only 
LUNs attached to QEMU target 0 are reported.

I can try this with virtio-scsi later today. I don't really have a lot 
of knowledge there, but it doesn't really seem to work the same way. One 
of the differences seems to be that virtio has a 
VIRTIO_SCSI_S_BAD_TARGET response code, which implies an internal 
knowledge of multiple targets that SRP does not have. FreeBSD's virtio 
driver just uses this to map the bus to multiple targets and hides the 
fact that LUNs are the fundamental unit, presenting discrete targets to 
the kernel SCSI subsystem. This isn't possible with SRP.

The command-line in question was just:
qemu-system-ppc64 -cdrom FreeBSD-10.0-ALPHA4-powerpc-powerpc64-disc1.iso

If you make the CDROM be a LUN on target 0, this will boot. Otherwise, 
it will not be able to find the CD drive.
-Nathan