linux-kernel - Re: virtio scsi host draft specification, v3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 01 Jul 2011 10:35:44 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Hannes Reinecke <hare@...e.de>
CC:	Stefan Hajnoczi <stefanha@...il.com>,
	Christoph Hellwig <chellwig@...hat.com>,
	Stefan Hajnoczi <stefanha@...ux.vnet.ibm.com>,
	kvm@...r.kernel.org, "Michael S. Tsirkin" <mst@...hat.com>,
	qemu-devel <qemu-devel@...gnu.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Virtualization <virtualization@...ts.linux-foundation.org>,
	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
Subject: Re: virtio scsi host draft specification, v3

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:

     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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/