Re: [Qemu-devel] virtio scsi host draft specification, v3

[Hai Dong,Li]

On 07/01/2011 09:14 AM, Hannes Reinecke wrote:
> > Actually, the kernel does _not_ do a LUN remapping.
>
> Not the kernel, the in-kernel target.  The in-kernel target can and will
> map hardware LUNs (target_lun in drivers/target/*) to arbitrary LUNs
> (mapped_lun).
>
> > > Put in another way: the virtio-scsi device is itself a SCSI
> > > target,
> >
> > Argl. No way. The virtio-scsi device has to map to a single LUN.
>
> I think we are talking about different things. By "virtio-scsi device"
> I meant the "virtio-scsi HBA".  When I referred to a LUN as seen by the
> guest, I was calling it a "virtual SCSI device".  So yes, we were
> calling things with different names.  Perhaps from now on
> we can call them virtio-scsi {initiator,target,LUN} and have no
> ambiguity?  I'll also modify the spec in this sense.
>
> > The SCSI spec itself only deals with LUNs, so anything you'll read in
> > there obviously will only handle the interaction between the
> > initiator (read: host) and the LUN itself. However, the actual
> > command is send via an intermediat target, hence you'll always see
> > the reference to the ITL (initiator-target-lun) nexus.
>
> Yes, this I understand.
>
> > The SCSI spec details discovery of the individual LUNs presented by a
> > given target, it does _NOT_ detail the discovery of the targets
> > themselves.  That is being delegated to the underlying transport
>
> And in fact I have this in virtio-scsi too, since virtio-scsi _is_ a
> transport:
Oh, here I catch up. I was wondering why there're ordering issues when 
talking
about virtio-scsi, since in SAM3, the third and the last paragraph of 
section
4.6.3 Request/Response ordering clearly describe it:

The manner in which ordering constraints are established is vendor 
specific. An
implementation may delegate this responsibility to the application client
(e.g., the device driver). In-order delivery may be an intrinsic property of
the service delivery subsystem or a requirement established by the SCSI
transport protocol standard.

To simplify the description of behavior, the SCSI architecture model assumes
in-order delivery of requests or responses to be a property of the service
delivery subsystem. This assumption does not constitute a requirement.  The
SCSI architecture model makes no assumption about and places no 
requirement on
the ordering of requests or responses for different I_T nexuses.

So if I understand correctly, virtio-scsi looks like an SCSI tranport 
protocol,
such as iSCSI, FCP and SRP which use tcp/ip, FC and Infiniband RDMA
respectively as the transfer media while virtio-scsi uses virtio, an 
virtual IO
channel, as the transfer media?

>     When VIRTIO_SCSI_EVT_RESET_REMOVED or VIRTIO_SCSI_EVT_RESET_RESCAN
>     is sent for LUN 0, the driver should ask the initiator to rescan
>     the target, in order to detect the case when an entire target has
>     appeared or disappeared.
>
>     [If the device fails] to report an event due to missing buffers,
>     [...] the driver should poll the logical units for unit attention
>     conditions, and/or do whatever form of bus scan is appropriate for
>     the guest operating system.
>
> > In the case of NPIV it would make sense to map the virtual SCSI host
> >  to the backend, so that all devices presented to the virtual SCSI
> > host will be presented to the backend, too. However, when doing so
> > these devices will normally be referenced by their original LUN, as
> > these will be presented to the guest via eg 'REPORT LUNS'.
>
> Right.
>
> > The above thread now tries to figure out if we should remap those LUN
> > numbers or just expose them as they are. If we decide on remapping,
> > we have to emulate _all_ commands referring explicitely to those LUN
> > numbers (persistent reservations, anyone?).
>
> But it seems to me that commands referring explicitly to LUN numbers
> most likely have to be reimplemented anyway for virtualization.  I'm
> thinking exactly of persistent reservations.  If two guests on the same
> host try a persistent reservation, they should conflict with each other.
> If reservation commands were just passed through, they would be seen
> as coming from the same initiator (the HBA driver or iSCSI initiator in
> the host OS).
>
> etc.
>
> > If we don't, we would expose some hardware detail to the guest, but
> > would save us _a lot_ of processing.
>
> But can we afford it?  And would the architecture allow that at all?
>
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html