From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [PATCH 3/4] exec, memory: Call to xen_modified_memory. Date: Tue, 17 Jul 2012 17:44:46 +0300 Message-ID: <50057A5E.1070602__21728.9784494371$1342536425$gmane$org@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50056FAB.8030404@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Anthony PERARD Cc: Luiz Capitulino , Anthony Liguori , Stefano Stabellini , QEMU-devel , Xen Devel List-Id: xen-devel@lists.xenproject.org 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? >> (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? -- error compiling committee.c: too many arguments to function