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

[Nikunj A Dadhania]

Nathan Whitehorn <address@hidden> writes:

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

What I see in slof code wrt the above in board-qemu/slof/vio-vscsi.fs:


\ We use SRP luns of the form 8000 | (bus << 8) | (id << 5) | lun
\ in the top 16 bits of the 64-bit LUN

Thats the reason I suppose you would not find anything at 0.

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


Regards
Nikunj