From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMMOm-0002Ha-Qk for qemu-devel@nongnu.org; Tue, 17 May 2011 11:41:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMMOl-0005SD-Ug for qemu-devel@nongnu.org; Tue, 17 May 2011 11:41:28 -0400 Received: from verein.lst.de ([213.95.11.211]:56784 helo=newverein.lst.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMMOl-0005S1-Po for qemu-devel@nongnu.org; Tue, 17 May 2011 11:41:27 -0400 Date: Tue, 17 May 2011 17:41:26 +0200 From: Christoph Hellwig Message-ID: <20110517154126.GA27700@lst.de> References: <20110516181023.7142.33402.sendpatchset@skannery> <20110516202354.GA8955@lst.de> <4DD192BD.3030200@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD192BD.3030200@codemonkey.ws> Subject: Re: [Qemu-devel] [RFC Patch 0/3]Qemu: Enable dynamic cache change through qemu monitor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Supriya Kannery , Prerna Saxena , Christoph Hellwig , qemu-devel@nongnu.org On Mon, May 16, 2011 at 04:10:21PM -0500, Anthony Liguori wrote: > To further clarify: > > Today cache=none|writethrough|writeback does two things. It: > > 1) Changes the WCE flag that's visible to the guest > > 2) Determines whether the host page cache is used for doing guest I/O > > As Christoph is very correct in pointing out, we cannot change (1) at run > time because this is guest visible. You will break a guest if you do this. > > But it's still desirable to be able to change (2) at run time. Before we > can do this properly though, we need to separate out the logic for setting > (1) vs. (2). > > And ideally, we would allow (1) to be changed by the guest itself at run > time which allows for full dynamic control. This is what he's referring to > below. Exactly. Setting/clearing the BDRV_O_NO_FLUSH also seems useful, maybe in addition to also allowing an equivalent for the writethrough modes.