From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBNFE-0005FH-4k for qemu-devel@nongnu.org; Mon, 19 Aug 2013 07:03:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBNF8-00043Y-3h for qemu-devel@nongnu.org; Mon, 19 Aug 2013 07:03:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBNF7-00043H-Pd for qemu-devel@nongnu.org; Mon, 19 Aug 2013 07:03:26 -0400 Date: Mon, 19 Aug 2013 14:05:10 +0300 From: "Michael S. Tsirkin" Message-ID: <20130819110510.GA21552@redhat.com> References: <1376347400-21035-1-git-send-email-mst@redhat.com> <1376347400-21035-2-git-send-email-mst@redhat.com> <5211EC7D.8040209@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5211EC7D.8040209@redhat.com> Subject: Re: [Qemu-devel] [PATCH v3 1/2] memory: export migration page size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Peter Maydell , pbonzini@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com On Mon, Aug 19, 2013 at 11:59:25AM +0200, Laszlo Ersek wrote: > On 08/13/13 00:43, Michael S. Tsirkin wrote: > > Migration code assumes that each RAM block is a multiple of target page > > size. > > Isn't that a valid assumption, considering the TARGET_PAGE_ALIGN() macro > call in qemu_ram_alloc_from_ptr() [exec.c]? > > > We can fix this in a variety of ways, the simplest way is > > exporting the required page size so callers can make regions > > large enough. > > > > Signed-off-by: Michael S. Tsirkin > > --- > > arch_init.c | 6 ++++++ > > include/exec/memory.h | 1 + > > 2 files changed, 7 insertions(+) > > > > diff --git a/arch_init.c b/arch_init.c > > index 68a7ab7..c62778f 100644 > > --- a/arch_init.c > > +++ b/arch_init.c > > @@ -150,6 +150,12 @@ int qemu_read_default_config_files(bool userconfig) > > return 0; > > } > > > > +/* Smallest page size for migrated RAM. */ > > +uint64_t qemu_migration_page_size(void) > > +{ > > + return TARGET_PAGE_SIZE; > > +} > > + > > static inline bool is_zero_page(uint8_t *p) > > { > > return buffer_find_nonzero_offset(p, TARGET_PAGE_SIZE) == > > diff --git a/include/exec/memory.h b/include/exec/memory.h > > index ebe0d24..6ffffa2 100644 > > --- a/include/exec/memory.h > > +++ b/include/exec/memory.h > > @@ -1055,6 +1055,7 @@ void *address_space_map(AddressSpace *as, hwaddr addr, > > void address_space_unmap(AddressSpace *as, void *buffer, hwaddr len, > > int is_write, hwaddr access_len); > > > > +extern uint64_t qemu_migration_page_size(void); > > > > #endif > > External linkage functions that are defined in "arch_init.c", and relate > to migration -- for example, skipped_mig_bytes_transferred() -- are > declared in "include/migration/migration.h". They seem to use > TARGET_PAGE_SIZE too. > > What justifies declaring this new function in "include/exec/memory.h"? > > Thanks, > Laszlo Well, this one is a bit different as this just helps device allocate the right amount of RAM. It doesn't deal with migration directly. -- MST