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:	Wed, 29 Jun 2011 06:07:52 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Stefan Hajnoczi <stefanha@...il.com>
Cc:	Paolo Bonzini <pbonzini@...hat.com>,
	Hannes Reinecke <hare@...e.de>,
	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 Wed, Jun 29, 2011 at 10:39:42AM +0100, Stefan Hajnoczi wrote:
> I think we're missing a level of addressing.  We need the ability to
> talk to multiple target ports in order for "list target ports" to make
> sense.  Right now there is one implicit target that handles all
> commands.  That means there is one fixed I_T Nexus.
> 
> If we introduce "list target ports" we also need a way to say "This
> CDB is destined for target port #0".  Then it is possible to enumerate
> target ports and address targets independently of the LUN field in the
> CDB.
> 
> I'm pretty sure this is also how SAS and other transports work.  In
> their framing they include the target port.

Yes, exactly.  Hierachial LUNs are a nasty fringe feature that we should
avoid as much as possible, that is for everything but IBM vSCSI which is
braindead enough to force them.

> The question is whether we really need to support multiple targets on
> a virtio-scsi adapter or not.  If you are selectively mapping LUNs
> that the guest may access, then multiple targets are not necessary.
> If we want to do pass-through of the entire SCSI bus then we need
> multiple targets but I'm not sure if there are other challenges like
> dependencies on the transport (Fibre Channel, SAS, etc) which make it
> impossible to pass through bus-level access?

I don't think bus-level pass through is either easily possible nor
desirable.  What multiple targets are useful for is allowing more
virtual disks than we have virtual PCI slots.  We could do this by
supporting multiple LUNs, but given that many SCSI ressources are
target-based doing multiple targets most likely is the more scabale
and more logical variant.  E.g. we could much more easily have one
virtqueue per target than per LUN.

--
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/