From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nom2o-0003Ra-38 for qemu-devel@nongnu.org; Mon, 08 Mar 2010 18:07:26 -0500 Received: from [199.232.76.173] (port=50235 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nom2i-0003A2-Rr for qemu-devel@nongnu.org; Mon, 08 Mar 2010 18:07:20 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nolrc-0001Zu-VR for qemu-devel@nongnu.org; Mon, 08 Mar 2010 17:55:57 -0500 Received: from mail2.shareable.org ([80.68.89.115]:44777) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Nolrb-0001Y2-Pf for qemu-devel@nongnu.org; Mon, 08 Mar 2010 17:55:52 -0500 Date: Mon, 8 Mar 2010 22:55:42 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] bs->enable_write_cache and the guest ABI Message-ID: <20100308225542.GB16057@shareable.org> References: <4B93BB4A.8090605@redhat.com> <20100308093908.GA1914@lst.de> <20100308094732.GB2869@shareable.org> <20100308170042.GA16826@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100308170042.GA16826@lst.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Avi Kivity , qemu-devel Christoph Hellwig wrote: > On Mon, Mar 08, 2010 at 09:47:32AM +0000, Jamie Lokier wrote: > > Assuming the outcome is that it becomes a qdev property, and stays > > preserved across migrations, even if the backing device access > > changes, then I think the right thing is to dynamically decide to set > > O_DSYNC and/or call fdatasync before completing writes from qemu when > > the guest thinks enable_write_cache=0 (or sets it to 0). With > > cache=none, that would set O_DSYNC|O_DIRECT if the two flags do work > > properly together on our favourite hosts. > > > > Thus enable_write_cache won't always have the default value for the > > different backing device access type, but it will match the guest's > > expectations and be actually safe. Moreover more, by responding to > > the guest changing that, it's closer to behaving like real harware. > > I'd have to look at other uses of qdev, but I would assume that we > always look at the qdev properties and only use the existing drive > suboptions as compatiblity if we do not have the qdev properties set. I'm not sure if I was clear or not: I mean if the guest runs "hdparm -W $value" or Windows equivalent, and cache!=writethrough, it should have the effect of turning on/off the host's O_DSYNC flag (or qemu calling fdatasync() before signalling every write completion), because that's really just another way for the guest say it wants to flush write caches after every write. So that's what the emulation should do, either explicitly (fdatasync) or a subtler way (O_DSYNC). That guest-visible flag, which is part of the emulated drive state, should be preserved across migration. -- Jamie