From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1JfR38-0006VR-Rl
	for qemu-devel@nongnu.org; Fri, 28 Mar 2008 22:44:06 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1JfR37-0006UZ-Bh
	for qemu-devel@nongnu.org; Fri, 28 Mar 2008 22:44:06 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1JfR37-0006US-44
	for qemu-devel@nongnu.org; Fri, 28 Mar 2008 22:44:05 -0400
Received: from mail.codesourcery.com ([65.74.133.4])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1JfR36-00033R-MD
	for qemu-devel@nongnu.org; Fri, 28 Mar 2008 22:44:04 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush
	request
Date: Sat, 29 Mar 2008 02:43:58 +0000
References: <20080328150517.GA18077@dmt>
	<200803290202.54431.paul@codesourcery.com>
	<20080329021126.GD30219@shareable.org>
In-Reply-To: <20080329021126.GD30219@shareable.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="ansi_x3.4-1968"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200803290243.59178.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
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: Jamie Lokier <jamie@shareable.org>
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>, qemu-devel@nongnu.org

On Saturday 29 March 2008, Jamie Lokier wrote:
> Paul Brook wrote:
> > > That'll depend on what kind of device is emulated.  Does the SCSI
> > > emulation handle multiple in-flight commands with any guarantee on
> > > order?
> >
> > SCSI definitely allows (and we emulate) multiple in flight commands.
> > I can't find any requirement that writes must complete before a
> > subsequent SYNCHRONISE_CACHE. However I don't claim to know the spec
> > that well,
>
> Aren't there SCSI tagged barrier commands or something like that,
> which allow a host to request ordering between commands?

Ah, yes. Ordering is defined as part of the task management model, not part of 
the commands themselves.  For parallel scsi barrier tasks are created  using 
the ORDERED message (The implementation for this in the LSI HBA is currently 
absent).

So in theory we don't care about this for SCSI because ordering will already 
have been enforced by upper levels.

Paul