From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:35405)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1QHy1E-0005uu-KZ
	for qemu-devel@nongnu.org; Thu, 05 May 2011 08:51:01 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <hch@lst.de>) id 1QHy1D-0007Hj-QE
	for qemu-devel@nongnu.org; Thu, 05 May 2011 08:51:00 -0400
Received: from verein.lst.de ([213.95.11.211]:45615 helo=newverein.lst.de)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1QHy1D-0007HS-LD
	for qemu-devel@nongnu.org; Thu, 05 May 2011 08:50:59 -0400
Date: Thu, 5 May 2011 14:50:58 +0200
From: Christoph Hellwig <hch@lst.de>
Message-ID: <20110505125058.GA24197@lst.de>
References: <4DC1D30F.4070408@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4DC1D30F.4070408@redhat.com>
Subject: Re: [Qemu-devel] virtio-scsi spec, first public draft
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: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, Hannes Reinecke <hare@suse.de>

>     #define VIRTIO_SCSI_T_BARRIER         0x80000000
> 
>     The type identifies the remaining fields.  The value
>     VIRTIO_SCSI_T_BARRIER can be ORed in the type as well.  This bit
>     indicates that this request acts as a barrier and that all preceding
>     requests must be complete before this one, and all following requests
>     must not be started until this is complete.  Note that a barrier
>     does not flush caches in the underlying backend device in host,
>     and thus does not serve as data consistency guarantee.  The driver
>     must send a SYNCHRONIZE CACHE command to flush the host cache.

Please don't repeat the barrier mistake done in the Xen and virtio-blk/lguest
protocols.  It really doesn't make sense to put this kind of strict odering
in.  If we really want ordering let's do it using SCSI ordered tags at least
to use a standard implementation.

And SCSI already supports the FUA bit to force a write to be writethrough,
even if the QEMU SCSI code doesn't implement.

Let's just make virtio-scsi purely a transport and not added magic features
into it.