From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: [PATCH 3/3] Add KVM support to QEMU Date: Wed, 29 Oct 2008 14:39:57 +0200 Message-ID: <4908599D.8030502@redhat.com> References: <1225224814-9875-1-git-send-email-aliguori@us.ibm.com> <1225224814-9875-2-git-send-email-aliguori@us.ibm.com> <1225224814-9875-3-git-send-email-aliguori@us.ibm.com> <49078707.5000109@redhat.com> <49078955.2090109@codemonkey.ws> <5d6222a80810281604g39708040kf710725dce6413dd@mail.gmail.com> <4907A1FA.2060106@codemonkey.ws> <490832C3.4060602@redhat.com> <20081029123523.GG4269@poweredge.glommer> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Glauber Costa , qemu-devel@nongnu.org, Gerd Hoffmann , kvm-devel To: Glauber Costa Return-path: Received: from mx2.redhat.com ([66.187.237.31]:45783 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752664AbYJ2MkG (ORCPT ); Wed, 29 Oct 2008 08:40:06 -0400 In-Reply-To: <20081029123523.GG4269@poweredge.glommer> Sender: kvm-owner@vger.kernel.org List-ID: Glauber Costa wrote: >>> Another place "hook" is updating a slot's dirty bitmap. Right now, >>> with my patchset we don't have live migration or the VGA RAM >>> optimization. There's nothing about the VGA RAM optimization that >>> wouldn't work for QEMU. I'm not sure that it really is an >>> optimization in the context of TCG, but I certainly don't think it's >>> any worse. The only thing you really need is to query the KVM dirty >>> bitmap when it comes time to enable start over querying the VGA dirty >>> bits. >>> >> I don't understand this. The VGA optimization really is qemu's, the kvm >> modifications only cater to the different way of getting the dirty bits. >> > > As it seems to me, the real difference is that qemu has to explicitly set > certain regions as dirty, while kvm get dirty bit "automatically" from the kernel. > > I'm completely lost. I don't see how one or the other is more or less automatic, or how qemu has to explicitly set regions as dirty (except when emulating bitblt). > So I believe we can have markers on the code to refresh dirty bitmap for certain > area ranges (for kvm use), and also enable a manual override (for qemu). After that, > the cpu_physical_memory_get_dirty() will simply return whether or not the page is > dirty. > Does not cpu_p_m_g_dirty() simply return whether or not the page is dirty now? > Also, kvm only tracks "dirty" bits, whereas qemu has at least three kinds of them. > But I think for now we can assume that kvm's dirty mean "all dirty kvm's dirty bits mean that kvm has seen the page written to since the last query. A zero doesn't mean the page is clean though -- it could have been written to by qemu. -- error compiling committee.c: too many arguments to function