From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQ3T4-0004oH-L3 for qemu-devel@nongnu.org; Mon, 14 Nov 2011 15:49:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQ3T3-0007cI-GB for qemu-devel@nongnu.org; Mon, 14 Nov 2011 15:49:26 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:52288) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQ3T3-0007cD-B2 for qemu-devel@nongnu.org; Mon, 14 Nov 2011 15:49:25 -0500 Received: by ggnr4 with SMTP id r4so634446ggn.4 for ; Mon, 14 Nov 2011 12:49:24 -0800 (PST) Message-ID: <4EC17ED1.5060007@codemonkey.ws> Date: Mon, 14 Nov 2011 14:49:21 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1321113420-3252-1-git-send-email-aliguori@us.ibm.com> <1321113420-3252-5-git-send-email-aliguori@us.ibm.com> <4EC1214B.8050105@us.ibm.com> <4EC170C9.5060202@codemonkey.ws> <4EC175D5.1000906@redhat.com> <4EC17610.3000401@codemonkey.ws> <4EC17BCF.4040202@redhat.com> In-Reply-To: <4EC17BCF.4040202@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 5/7] block: allow migration to work with image files (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Lucas Meneghel Rodrigues , Stefan Hajnoczi , "Michael S. Tsirkin" , quintela@redhat.com, qemu-devel@nongnu.org, Avi Kivity On 11/14/2011 02:36 PM, Kevin Wolf wrote: > Am 14.11.2011 21:12, schrieb Anthony Liguori: >>> I don't think it makes even sense logically: bdrv_invalidate_cache() >>> means "throw all your caches away and refetch everything from disk". >>> What do we gain from doing this on stop? To some degree I could >>> understand if you did it on cont, so that you can modify an image on the >>> host while the VM is stopped (though I would still consider it criminal >>> :-)). >> >> Michael basically was trying to avoid having a VM's state change after you >> stopped the guest. >> >> With something like cache=unsafe that periodically flushes based on a timer (I >> think), you want to make sure that that doesn't happen after stop occurs. > > This is a good point, but neither does cache=unsafe use a timer nor can > I see how invalidating the cache would avoid such behaviour. And > throwing away any unwritten changes doesn't really make it better. I don't think there's any real harm to removing it so I'll remove it in the next rev. Regards, Anthony Liguori > > Kevin >