From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxB8T-00026i-Ms for qemu-devel@nongnu.org; Tue, 26 May 2015 05:26:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxB8P-0001EV-NT for qemu-devel@nongnu.org; Tue, 26 May 2015 05:26:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxB8P-0001Cu-Gu for qemu-devel@nongnu.org; Tue, 26 May 2015 05:26:53 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4Q9Qqq0024674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 26 May 2015 05:26:53 -0400 Message-ID: <55643C58.3060801@redhat.com> Date: Tue, 26 May 2015 11:26:48 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1430152117-100558-1-git-send-email-pbonzini@redhat.com> <1430152117-100558-12-git-send-email-pbonzini@redhat.com> <20150526084031.GL13749@ad.nay.redhat.com> <556437B9.1060600@redhat.com> <20150526092219.GA27391@ad.nay.redhat.com> In-Reply-To: <20150526092219.GA27391@ad.nay.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 11/29] memory: include DIRTY_MEMORY_MIGRATION in the dirty log mask List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: qemu-devel@nongnu.org, stefanha@redhat.com, mst@redhat.com On 26/05/2015 11:22, Fam Zheng wrote: >>>> > > > @@ -1329,7 +1329,11 @@ bool memory_region_is_skip_dump(MemoryRegion *mr) >>>> > > > >>>> > > > uint8_t memory_region_get_dirty_log_mask(MemoryRegion *mr) >>>> > > > { >>>> > > > - return mr->dirty_log_mask; >>>> > > > + uint8_t mask = mr->dirty_log_mask; >>>> > > > + if (global_dirty_log) { >>>> > > > + mask |= (1 << DIRTY_MEMORY_MIGRATION); >>> > > >>> > > This is ugly, but I don't know how to do differently. :( >> > >> > Why do you think it's ugly? >> > As long as the log_start/log_stop callbacks >> > are handled properly, I think it's okay. > Ugly in the per object function relying on a global to propogate the new value. Yes, but that's the point of the patch. :) It lets the listeners track updates to the local state of the MemoryRegion instead of having to track the global state. So it's somewhat ugly, but it is less ugly than tracking exactly the same global state in exec.c (core_log_global_start) and kvm-all.c (kvm_log_global_start). Does this make sense? Paolo