From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrPh0-0007sJ-8E for qemu-devel@nongnu.org; Wed, 18 Jul 2012 04:33:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SrPgu-00079O-DP for qemu-devel@nongnu.org; Wed, 18 Jul 2012 04:33:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrPgu-00078D-54 for qemu-devel@nongnu.org; Wed, 18 Jul 2012 04:33:04 -0400 Message-ID: <500674B7.4040506@redhat.com> Date: Wed, 18 Jul 2012 11:32:55 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1342531805-29894-1-git-send-email-anthony.perard@citrix.com> <1342531805-29894-4-git-send-email-anthony.perard@citrix.com> <50056AA1.9010004@redhat.com> <50056FAB.8030404@citrix.com> <50057A5E.1070602@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/4] exec, memory: Call to xen_modified_memory. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Anthony Perard , Anthony Liguori , Luiz Capitulino , QEMU-devel , Xen Devel On 07/17/2012 09:36 PM, Stefano Stabellini wrote: > On Tue, 17 Jul 2012, Avi Kivity wrote: >> On 07/17/2012 04:59 PM, Anthony PERARD wrote: >> >> >> >> This is pretty ugly. An alternative is to set up a periodic bitmap scan >> >> that looks at the qemu dirty bitmap and calls xen_modified_memory() for >> >> dirty page ranges, and clears the bitmap for the next pass. Is it >> >> workable? >> > >> > I don't think a periodic scan can do anything useful, unfortunately. >> >> Why not? > > I vaguely remember that we used to have a bitmap years ago, but, aside from > making the code much more complicated, it caused blue screens on > intensive disk accesses. Surely it was some bug, not the scan itself. > > >> >> (is xen_modified_memory a hypercall, or does it maintain an in-memory >> >> structure?) >> > >> > It's an hypercall. The function do something (call the hypercall) only >> > during migration, otherwise it return immediately. >> >> I see. I guess it isn't expensive for you because there isn't much dma >> done by qemu usually with xen (unlike kvm where pv block devices are >> implemented in qemu). >> >> How about pushing the call into cpu_physical_memory_set_dirty_flags()? >> Would that reduce the number of call sites? > > Pushing the calls to cpu_physical_memory_set_dirty_flags and > cpu_physical_memory_set_dirty_range would make the code much nicer. > However being these functions in exec-obsolete.h, are they at risk of > removal? exec-obsolete.h just means don't add new call sites. The functions won't be removed, instead they'll be absorbed into the memory code with different names and different implementations. -- error compiling committee.c: too many arguments to function