From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [Xen-devel] [PATCH] xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER Date: Wed, 25 Apr 2012 13:23:35 +0200 Message-ID: <20120425112335.GA20868@lst.de> References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120425084524.GA17537@lst.de> <1335344565.28015.7.camel@zakaz.uk.xensource.com> <20120425102024.GA19800@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Stefano Stabellini Cc: "kwolf@redhat.com" , "xen-devel@lists.xensource.com" , Ian Campbell , "konrad.wilk@oracle.com" , "qemu-devel@nongnu.org" , Christoph Hellwig List-Id: xen-devel@lists.xenproject.org On Wed, Apr 25, 2012 at 12:21:53PM +0100, Stefano Stabellini wrote: > That is true, in fact I couldn't figure out what I had to implement just > reading the comment. So I went through the blkback code and tried to > understand what I had to do, but I got it wrong. > > Reading the code again it seems to me that BLKIF_OP_FLUSH_DISKCACHE > is supposed to have the same semantics as REQ_FLUSH, that implies a > preflush if nr_segments > 0, not a postflush like I did. It's worse - blkfront translates both a REQ_FLUSH or a REQ_FUA into BLKIF_OP_FLUSH_DISKCACHE. REQ_FLUSH either is a pre flush or a pure flush without a data transfer, and REQ_FUA is a post flush. So to get the proper semantics you'll have to do both, _and_ sequence it so that no operation starts before the previous one finished.