From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Lysgt-0002bC-6N
	for qemu-devel@nongnu.org; Tue, 28 Apr 2009 15:10:03 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Lysgo-0002V0-Qf
	for qemu-devel@nongnu.org; Tue, 28 Apr 2009 15:10:02 -0400
Received: from [199.232.76.173] (port=52861 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Lysgo-0002Ug-FZ
	for qemu-devel@nongnu.org; Tue, 28 Apr 2009 15:09:58 -0400
Received: from mtagate7.de.ibm.com ([195.212.29.156]:62670)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <borntraeger@de.ibm.com>) id 1Lysgn-0004CH-Vp
	for qemu-devel@nongnu.org; Tue, 28 Apr 2009 15:09:58 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate7.de.ibm.com (8.14.3/8.13.8) with ESMTP id n3SJ9tNN106034
	for <qemu-devel@nongnu.org>; Tue, 28 Apr 2009 19:09:55 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com
	[9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with
	ESMTP id n3SJ9tqd4063390
	for <qemu-devel@nongnu.org>; Tue, 28 Apr 2009 21:09:55 +0200
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP
	id n3SJ9s48027961
	for <qemu-devel@nongnu.org>; Tue, 28 Apr 2009 21:09:55 +0200
From: Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: [Qemu-devel] Re: [PATCH] virtio-blk: add SGI_IO passthru support
Date: Tue, 28 Apr 2009 21:09:52 +0200
References: <20090427082606.GA32604@lst.de> <49F5C303.3060003@codemonkey.ws>
	<20090428095154.GB4137@lst.de>
In-Reply-To: <20090428095154.GB4137@lst.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200904282109.52905.borntraeger@de.ibm.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>, Rusty Russell <rusty@rustcorp.com.au>, qemu-devel@nongnu.org, kvm@vger.kernel.org

Am Tuesday 28 April 2009 11:51:54 schrieb Christoph Hellwig:
> Not quite yet.  Eventually I want to support a virtio-scsi kind of
> transport which would use the same virtio-blk protocol but only send
> scsi commands.  We'd need a different driver on the Linux side for
> it that registers to the scsi layer.  On the QEMU side it could either
> do pass-through to a real scsi device using SG_IO or use the existing

Yes, virtio-scsi is also something we were thinking of. The last time we discussed this idea of SCSI passthrough internally, we stumbled over error recovery. Who is responsible for the error recovery? The host, the guest, or both? Are there problems, which will trigger error recovery in the guest and host midlayer at the same time? To be honest, my scsi knowledge is very limited, so I dont know if that is a real problem.

Christian