From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KvALH-0002Rb-Go for qemu-devel@nongnu.org; Wed, 29 Oct 2008 08:40:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KvALG-0002QO-2b for qemu-devel@nongnu.org; Wed, 29 Oct 2008 08:40:07 -0400 Received: from [199.232.76.173] (port=50937 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KvALF-0002QA-Ui for qemu-devel@nongnu.org; Wed, 29 Oct 2008 08:40:05 -0400 Received: from mx2.redhat.com ([66.187.237.31]:59771) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KvALE-0000tk-Fi for qemu-devel@nongnu.org; Wed, 29 Oct 2008 08:40:05 -0400 Message-ID: <4908599D.8030502@redhat.com> Date: Wed, 29 Oct 2008 14:39:57 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 3/3] Add KVM support to QEMU 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> In-Reply-To: <20081029123523.GG4269@poweredge.glommer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: Glauber Costa , kvm-devel , qemu-devel@nongnu.org, Gerd Hoffmann 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