|
From: | Nathan Whitehorn |
Subject: | Re: [Qemu-ppc] Bug with REPORT LUNS in IBM VSCSI |
Date: | Wed, 02 Oct 2013 11:05:53 -0500 |
User-agent: | Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 |
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#L1989The 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
[Prev in Thread] | Current Thread | [Next in Thread] |