From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NoaW0-0006QZ-Si for qemu-devel@nongnu.org; Mon, 08 Mar 2010 05:48:48 -0500 Received: from [199.232.76.173] (port=40616 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NoaVz-0006Q7-NR for qemu-devel@nongnu.org; Mon, 08 Mar 2010 05:48:47 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NoaVy-0002HB-Uw for qemu-devel@nongnu.org; Mon, 08 Mar 2010 05:48:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3633) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NoaVy-0002H3-Fw for qemu-devel@nongnu.org; Mon, 08 Mar 2010 05:48:46 -0500 Message-ID: <4B94D60A.7070006@redhat.com> Date: Mon, 08 Mar 2010 12:48:42 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4B93BB4A.8090605@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: bs->enable_write_cache and the guest ABI List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: qemu-devel , Christoph Hellwig On 03/08/2010 12:29 PM, Juan Quintela wrote: > Avi Kivity wrote: > >> block.c says: >> >> >>> /* >>> * Yes, BDRV_O_NOCACHE aka O_DIRECT means we have to present a >>> * write cache to the guest. We do need the fdatasync to flush >>> * out transactions for block allocations, and we maybe have a >>> * volatile write cache in our backing device to deal with. >>> */ >>> if (flags& (BDRV_O_CACHE_WB|BDRV_O_NOCACHE)) >>> bs->enable_write_cache = 1; >>> >> This means that if I start a guest with cache=writethrough and then >> restart (or live migrate) it with cache=none, then the guest will see >> a change, even though the user only changed the drive's backing, not >> something guest visible. In the case of live migration, the guest >> will not even notice the change and we may be at risk of data loss. >> >> For 0.13 I propose setting enable_write_cache to true unconditionally. >> For 0.12 the question is more difficult, since we'll be changing the >> guest ABI. Given that guests are unlikely not to be able to cope with >> write caches, and that the alternative is data loss, I believe that's >> also the right solution there. >> > For RHEL I setted with adding enable_write_cache to the migration > state. As you state, that value is guest visible. I can update that > patches to qemu. When I migrated from an old version, I just set that > value to 0. > > What do you think? > I think we have to go with a qdev property as Christoph suggests. Then it becomes the management's responsibility to set it right. -- error compiling committee.c: too many arguments to function