From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR1dr-0000yJ-A0 for qemu-devel@nongnu.org; Fri, 21 Mar 2014 11:46:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WR1dl-0003JN-DH for qemu-devel@nongnu.org; Fri, 21 Mar 2014 11:45:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR1dl-0003J3-58 for qemu-devel@nongnu.org; Fri, 21 Mar 2014 11:45:49 -0400 Date: Fri, 21 Mar 2014 15:45:41 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20140321154540.GD8476@work-vm> References: <1395399490-13295-1-git-send-email-dgilbert@redhat.com> <8761n7itlx.fsf@elfo.mitica> <20140321132224.GA22211@work-vm> <532C57A9.2060002@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <532C57A9.2060002@redhat.com> Subject: Re: [Qemu-devel] [PATCH 1/1] Count used RAMBlock pages for migration_dirty_pages List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Alexey Kardashevskiy , qemu-devel@nongnu.org, Juan Quintela * Paolo Bonzini (pbonzini@redhat.com) wrote: > Il 21/03/2014 14:22, Dr. David Alan Gilbert ha scritto: > >I don't think they overlap, but I worry that the end of one block > >and the start of the next might be on the same page. > >The code that got me worried was migration_bitmap_sync_range > >that seemd to be general; but actually that's worrying about 64bit words > >not pages. > >What happens with things like '/rom@etc/table-loader' which is only > >4k on x86 when they are on boxes with bigger target_page. > > Do you mean bigger host page? Yes. > RAM sizes are always rounded up to target page size: > > size = TARGET_PAGE_ALIGN(size); > > If I understand correctly all that matters here is ram addresses > have no remainder WRT target page sizes. OK, so I can simplify it back to last nights code from before I started worrying about it. > Host page sizes matter only for KVM (see hpratio in > cpu_physical_memory_set_dirty_lebitmap in include/exec/ram_addr.h). > In this case dirtying a 4K area also dirties 12K of adjacent > ram_addr_t. Things could go wrong if those ram_addr_t's are not part > of any RAMBlock, because in that case you will loop endlessly (I > think). But this is not something your patch introduces. No, actually I don't think it will loop; the code loops over all the RAM blocks, looking only at the bitmap bits that RAMBlocks->length cover; if the kernel sets bits outside the RAMBlocks then they'll get ignored. > So it looks like your patch could also fix the problem Juan reported > at http://article.gmane.org/gmane.comp.emulators.qemu/247462 -- but > perhaps only on hosts where !KVM || TARGET_PAGE_SIZE==getpagesize(). Possibly yes; I think that would cause gaps in the bitmap to have the same effect as the hot unplug. I'll rework the patch to my less paranoid version from yesterday that treats bitmap bits as belonging to only one RAMBlock and repost. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK