From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KvB1b-0002bR-IG for qemu-devel@nongnu.org; Wed, 29 Oct 2008 09:23:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KvB1Z-0002bF-1w for qemu-devel@nongnu.org; Wed, 29 Oct 2008 09:23:50 -0400 Received: from [199.232.76.173] (port=34778 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KvB1Y-0002bC-Tr for qemu-devel@nongnu.org; Wed, 29 Oct 2008 09:23:48 -0400 Received: from mx2.redhat.com ([66.187.237.31]:52593) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KvB1Y-0000aZ-8T for qemu-devel@nongnu.org; Wed, 29 Oct 2008 09:23:48 -0400 Message-ID: <490863DC.5080803@redhat.com> Date: Wed, 29 Oct 2008 15:23:40 +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> <4908602E.2050000@codemonkey.ws> In-Reply-To: <4908602E.2050000@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; 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: Anthony Liguori Cc: Glauber Costa , Glauber Costa , qemu-devel@nongnu.org, kvm-devel , Gerd Hoffmann Anthony Liguori wrote: > Avi Kivity wrote: >> Anthony Liguori 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. > > Right. I'm just not sure that it's going to be as much of an > optimization for TCG as it is for KVM. When qemu is loaded certainly this is lost in the noise. But when idling (and as a bonus, the screen doesn't change much), tcg and kvm will benefit equally. > > Right now, in QEMU, code looks like this: > > for (i = 0; i < addr; i += TARGET_PAGE_SIZE) { > if (cpu_p_m_g_dirty(i, DIRTY_FLAG)) { > cpu_p_m_r_dirty(i, i + TARGET_PAGE_SIZE, DIRTY_FLAG); > > // do something with dirty memory > } > > All we need to do is add another cpu_physical_memory_sync_dirty(i, i + > REGION_SIZE, DIRTY_FLAG); that would go at the start of this. For > QEMU, this is a nop since dirty bits are updated as soon as they are > reset. For KVM, this would update the entire set of dirty bits for > the given memory region. You mean merge the kvm bitmap into the qemu bitmap? That's what it does now, no? > We also need something to enable dirty tracking for a particular > region. We already have something for migration, we could perhaps > extend that API (cpu_p_m_s_dirty_tracking). I don't think qemu would benefit much from per-region tracking, but maybe I'm wrong. -- error compiling committee.c: too many arguments to function