From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KvAZX-0001GF-NJ for qemu-devel@nongnu.org; Wed, 29 Oct 2008 08:54:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KvAZW-0001Fv-Sp for qemu-devel@nongnu.org; Wed, 29 Oct 2008 08:54:51 -0400 Received: from [199.232.76.173] (port=46927 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KvAZW-0001Fr-IS for qemu-devel@nongnu.org; Wed, 29 Oct 2008 08:54:50 -0400 Received: from mx2.redhat.com ([66.187.237.31]:57111) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KvAZT-0006D6-3z for qemu-devel@nongnu.org; Wed, 29 Oct 2008 08:54:48 -0400 Date: Wed, 29 Oct 2008 10:56:20 -0200 From: Glauber Costa Subject: Re: [Qemu-devel] Re: [PATCH 3/3] Add KVM support to QEMU Message-ID: <20081029125620.GH4269@poweredge.glommer> 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> <4908599D.8030502@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4908599D.8030502@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Glauber Costa , kvm-devel , qemu-devel@nongnu.org, Gerd Hoffmann On Wed, Oct 29, 2008 at 02:39:57PM +0200, Avi Kivity wrote: > 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). Or maybe I am. But I don't see any way in which qemu sets dirty bits but explicitly with cpu_physical_memory_set_dirty(). This is pretty explicit. > >> 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? If you look at the vga code, you see something like: cpu_physical_memory_get_dirty(page0, VGA_DIRTY_FLAG) | cpu_physical_memory_get_dirty(page1, VGA_DIRTY_FLAG); if (kvm_enabled()) { update |= bitmap_get_dirty(bitmap, (page0 - s->vram_offset) >> TARGET_PAGE_BITS); update |= bitmap_get_dirty(bitmap, (page1 - s->vram_offset) >> TARGET_PAGE_BITS); } so if the page is not dirty to cpu_p_m_g_dirty() (I liked that abb), it can still be dirty for kvm. Ideally, it would not be necessary. > >> 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. Right. The point here is more like kvm has 1 type of dirty whereas qemu has many.