From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ve5s6-0008AZ-JP for qemu-devel@nongnu.org; Wed, 06 Nov 2013 11:22:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ve5s0-0000Hc-JS for qemu-devel@nongnu.org; Wed, 06 Nov 2013 11:22:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24630) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ve5s0-0000HX-AI for qemu-devel@nongnu.org; Wed, 06 Nov 2013 11:22:16 -0500 From: Juan Quintela In-Reply-To: <527A66BA.7030906@redhat.com> (Paolo Bonzini's message of "Wed, 06 Nov 2013 16:56:42 +0100") References: <1383743088-8139-1-git-send-email-quintela@redhat.com> <1383743088-8139-37-git-send-email-quintela@redhat.com> <527A66BA.7030906@redhat.com> Date: Wed, 06 Nov 2013 17:22:12 +0100 Message-ID: <87ppqdxzyj.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 36/39] memory: move bitmap synchronization to its own function Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: chegu_vinod@hp.com, qemu-devel@nongnu.org, Alexander Graf Paolo Bonzini wrote: > Il 06/11/2013 14:04, Juan Quintela ha scritto: >> We want to have all the functions that handle directly the dirty >> bitmap near. We will change it later. > > Please move it to exec.c instead. > >> Signed-off-by: Juan Quintela >> --- >> include/exec/memory-physical.h | 31 +++++++++++++++++++++++++++++++ >> kvm-all.c | 27 ++------------------------- >> 2 files changed, 33 insertions(+), 25 deletions(-) >> >> diff --git a/include/exec/memory-physical.h b/include/exec/memory-physical.h >> index 610c55f..72faf06 100644 >> --- a/include/exec/memory-physical.h >> +++ b/include/exec/memory-physical.h >> @@ -72,6 +72,37 @@ static inline void cpu_physical_memory_set_dirty_range(ram_addr_t start, >> xen_modified_memory(start, length); >> } >> >> +static inline void cpu_physical_memory_set_dirty_lebitmap(unsigned long *bitmap, > > Why "le"? little endian, name is already too long (cpu_physical_memory_ is too big as a preffix.) > > Paolo > >> + ram_addr_t start, >> + ram_addr_t pages) >> +{ >> + unsigned int i, j; >> + unsigned long page_number, c; >> + hwaddr addr; >> + ram_addr_t ram_addr; >> + unsigned int len = (pages + HOST_LONG_BITS - 1) / HOST_LONG_BITS; >> + unsigned long hpratio = getpagesize() / TARGET_PAGE_SIZE; >> + >> + /* >> + * bitmap-traveling is faster than memory-traveling (for addr...) >> + * especially when most of the memory is not dirty. >> + */ >> + for (i = 0; i < len; i++) { >> + if (bitmap[i] != 0) { >> + c = leul_to_cpu(bitmap[i]); this is the important part. KVM maintains the bitmap is Little Endian mode, and PPC? I assme needs this. >> + do { >> + j = ffsl(c) - 1; >> + c &= ~(1ul << j); >> + page_number = (i * HOST_LONG_BITS + j) * hpratio; >> + addr = page_number * TARGET_PAGE_SIZE; >> + ram_addr = start + addr; >> + cpu_physical_memory_set_dirty_range(ram_addr, >> + TARGET_PAGE_SIZE >> * hpratio); I checked, and it appears that ppc really use the hpratio thing. I hope that the bitmap optimization also works for ppc, but its architecture is weird^Winteresting O:-) Alex?