> I've done some readings about this problem today, and I think I've got > an idea what might be wrong here - seems like a bug in SLOF to me. > > First, according to the SLOF source code, it seems to me that its > intention is to to scan target IDs, not channels (but as I haven't > written that part, I am not 100% sure here). > > Then I compared how Linux and SLOF fill the 64-bit LUN field in the > SRP_CMD request structure, and they both fill in the target ID at the > same location - but Linux is additionally setting an additional bit in > first byte (see the "lun_from_dev" function in ibmvscsi.c of the > kernel). > > Looking at the "SCSI Architecture Model" specification, this additional > bit is used to select the "Logical unit addressing method" instead of > the "Peripheral device addressing method" that SLOF currently uses - and > the "Logical unit addressing method" sounds more reasonable to me when > looking at the places where SLOF tries to fill in the target ID. > > So I suggest that I change SLOF to also use the "Logical unit > addressing method" like Linux does, which should result in the fact that > SLOF tries to scan the target IDs instead of the channels/bus IDs.
.../... Note that in addition to that, the PAPR spec specifies only one "device" (whatever that means) per vscsi instance. In fact, if we are ever to support proper sg, we need that, because the way our vscsi client driver works in linux, we can only pass one max request size down to the client from qemu, and without that information, sg cannot be done reliably. Cheers, Ben.
