From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NogK2-0005Qb-I4
	for qemu-devel@nongnu.org; Mon, 08 Mar 2010 12:00:50 -0500
Received: from [199.232.76.173] (port=56740 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NogK2-0005Q9-31
	for qemu-devel@nongnu.org; Mon, 08 Mar 2010 12:00:50 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <hch@lst.de>) id 1NogK0-0001Ij-GD
	for qemu-devel@nongnu.org; Mon, 08 Mar 2010 12:00:49 -0500
Received: from verein.lst.de ([213.95.11.210]:40576)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60)
	(envelope-from <hch@lst.de>) id 1NogK0-0001I1-0p
	for qemu-devel@nongnu.org; Mon, 08 Mar 2010 12:00:48 -0500
Date: Mon, 8 Mar 2010 18:00:42 +0100
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] bs->enable_write_cache and the guest ABI
Message-ID: <20100308170042.GA16826@lst.de>
References: <4B93BB4A.8090605@redhat.com> <20100308093908.GA1914@lst.de>
	<20100308094732.GB2869@shareable.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100308094732.GB2869@shareable.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: qemu-devel <qemu-devel@nongnu.org>, Christoph Hellwig <hch@lst.de>, Avi Kivity <avi@redhat.com>

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.