From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:42128)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from
	<BATV+5c4d58addf64ca498f06+2866+infradead.org+hch@bombadil.srs.infradead.org>)
	id 1Qbrzz-0006RH-Fy
	for qemu-devel@nongnu.org; Wed, 29 Jun 2011 06:28:00 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from
	<BATV+5c4d58addf64ca498f06+2866+infradead.org+hch@bombadil.srs.infradead.org>)
	id 1Qbrzx-0007gd-PH
	for qemu-devel@nongnu.org; Wed, 29 Jun 2011 06:27:59 -0400
Received: from 173-166-109-252-newengland.hfc.comcastbusiness.net
	([173.166.109.252]:43480 helo=bombadil.infradead.org)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from
	<BATV+5c4d58addf64ca498f06+2866+infradead.org+hch@bombadil.srs.infradead.org>)
	id 1Qbrzx-0007gT-DS
	for qemu-devel@nongnu.org; Wed, 29 Jun 2011 06:27:57 -0400
Date: Wed, 29 Jun 2011 06:27:50 -0400
From: Christoph Hellwig <hch@infradead.org>
Message-ID: <20110629102750.GA11648@infradead.org>
References: <1504884387.187692.1307716550265.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
	<4DF71E28.6070009@suse.de> <4E0AE36B.9010500@redhat.com>
	<BANLkTik2AXXkWvV23OP1eDdLirP2N0PC3A@mail.gmail.com>
	<20110629100752.GA27744@infradead.org> <4E0AFD2A.80102@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4E0AFD2A.80102@suse.de>
Subject: Re: [Qemu-devel] virtio scsi host draft specification, v3
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <chellwig@redhat.com>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel <qemu-devel@nongnu.org>, "Nicholas A. Bellinger" <nab@linux-iscsi.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Christoph Hellwig <hch@infradead.org>, Paolo Bonzini <pbonzini@redhat.com>, Linux Virtualization <virtualization@lists.linux-foundation.org>

On Wed, Jun 29, 2011 at 12:23:38PM +0200, Hannes Reinecke wrote:
> The general idea here is that we can support NPIV.
> With NPIV we'll have several scsi_hosts, each of which is assigned a
> different set of LUNs by the array.
> With virtio we need to able to react on LUN remapping on the array
> side, ie we need to be able to issue a 'REPORT LUNS' command and
> add/remove LUNs on the fly. This means we have to expose the
> scsi_host in some way via virtio.
> 
> This is impossible with a one-to-one mapping between targets and
> LUNs. The actual bus-level pass-through will be just on the SCSI
> layer, ie 'REPORT LUNS' should be possible. If and how we do a LUN
> remapping internally on the host is a totally different matter.
> Same goes for the transport details; I doubt we will expose all the
> dingy details of the various transports, but rather restrict
> ourselves to an abstract transport.

If we want to support traditional NPIV that's what we have to do.
I still hope we'll see broad SR-IOV support for FC adapters soon,
which would ease all this greatly.