From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGvcY-0007xL-I9 for qemu-devel@nongnu.org; Wed, 06 Jan 2016 16:27:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aGvcV-0003ib-CG for qemu-devel@nongnu.org; Wed, 06 Jan 2016 16:27:54 -0500 Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]:36971) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGvcV-0003iO-6V for qemu-devel@nongnu.org; Wed, 06 Jan 2016 16:27:51 -0500 Received: by mail-wm0-x22e.google.com with SMTP id f206so94725076wmf.0 for ; Wed, 06 Jan 2016 13:27:50 -0800 (PST) Sender: Paolo Bonzini References: <1447165546-27784-1-git-send-email-quintela@redhat.com> <1447165546-27784-50-git-send-email-quintela@redhat.com> From: Paolo Bonzini Message-ID: <568D86D2.7080507@redhat.com> Date: Wed, 6 Jan 2016 22:27:46 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 49/57] Round up RAMBlock sizes to host page sizes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite , Juan Quintela Cc: Amit Shah , "qemu-devel@nongnu.org Developers" , "Dr. David Alan Gilbert (git)" On 30/12/2015 01:26, Peter Crosthwaite wrote: > On Tue, Nov 10, 2015 at 6:25 AM, Juan Quintela wrote: >> From: "Dr. David Alan Gilbert" >> >> RAMBlocks that are not a multiple of host pages in length >> cause problems for postcopy (I've seen an ACPI table on aarch64 >> be 5k in length - i.e. 5x target-page), so round RAMBlock sizes >> up to a host-page. >> >> This potentially breaks migration compatibility due to changes >> in RAMBlock sizes; however: >> 1) x86 and s390 I think always have host=target page size >> 2) When I've tried on Power the block sizes already seem aligned. >> 3) I don't think there's anything else that maintains per-version >> machine-types for compatibility. >> > > Is there any reason this shouldn't be converted to > REAL_HOST_PAGE_ALIGN given these restrictions? > > I'm thinking about multi-arch, where HOST_PAGE_ALIGN is inaccessible > from exec.c as it is target-arch specific. My previous workaround was > to define the target page size for multi-arch so that TARGET_PAGE_SIZE > was usable but not sure that should go viral to these other defs. host_page_size and host_page_mask are really just MAX(host_page_size, TARGET_PAGE_SIZE) and MIN(qemu_host_page_mask, TARGET_PAGE_MASK). If you convert them to macros this way, the hack you use for multi-arch TARGET_PAGE_SIZE will work transparently for HOST_PAGE_{SIZE,MASK}. Paolo