Re: [Qemu-devel] [RFC PATCH 3/6] scsi-generic: allow customization of the lun

[Paolo Bonzini]

On 05/25/2011 03:10 PM, Christoph Hellwig wrote:
> On Fri, May 20, 2011 at 05:03:34PM +0200, Paolo Bonzini wrote:
> > This allows passthrough of devices with LUN != 0, by redirecting them to
> > LUN0 in the emulated target.
>
> I'm not quite sure what this code is for.  Each /dev/sg device reresents
> a LUN.  So if we want to suport multiple LUNs in qemu for devices that
> are backed by scsi-generic devices we need to take REPORT_LUNs emulation
> into the core scsi code, as any qemu target is completely independent
> of the underlying scsi device topology.

Yes, I did that.

The problem this patch solves is as follows.  scsi-generic rejects 
requests whose LUN does not match the host device's LUN.  However, since 
right now each scsi-disk and scsi-generic instance _must_ implement the 
whole target, this basically makes passthrough impossible when the 
device has a LUN that is not 0.

That said, this patch has now a completely different subject and meaning 
in my work branch.  I attach it FYI.

> > +    case INQUIRY:
> > +        if (req->lun != s->lun) {
>
> This seems odd.  I'd expect the SCSI core to handle the LUN addressing.
> For now that is just rejecting wrongs ones, and if multiple LUN
> support is added dispatching it to the correct drivers instance.

I agree.  This case of INQUIRY is needed because (for simplicity and 
backwards compatibility) you can hang a scsi-disk or scsi-generic device 
directly off the HBA, without the intermediate pseudo-device that 
handles dispatching commands and reporting LUNs.  In this case, the 
scsi-disk and scsi-generic devices see requests for other LUN than 
theirs.  In the case of INQUIRY and REQUEST SENSE, they must reply too.

A similar case happens with REPORT LUNS.  If a device's LUN is non-zero, 
the device will be attached to the intermediate pseudo-device, which 
will handle REPORT LUNS for it.  The simple REPORT LUNS code in 
scsi-disk and scsi-generic is only for the case in which the target has 
a single LUN.  That must be LUN 0 so the reply is hardcoded, and I'm 
asserting that the hardcoded reply is correct.  Note that I'm not 
asserting that the message is _sent_ to LUN 0; I'm asserting that the 
device itself is on LUN 0.

I thought about making REPORT LUNS really handled by the core, but it's 
a mess because I must put the answer in the buffer that scsi_req_get_buf 
will report.  The devices currently do not expose to the core a way to 
allocate that buffer, or to query its size.

Paolo

0001-scsi-generic-fix-passthrough-of-devices-with-LUN-0.patch
Description: Text Data