From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vksk9-0002ze-G3 for qemu-devel@nongnu.org; Mon, 25 Nov 2013 04:46:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vksk3-0004aR-Gf for qemu-devel@nongnu.org; Mon, 25 Nov 2013 04:46:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51551) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vksk3-0004aG-81 for qemu-devel@nongnu.org; Mon, 25 Nov 2013 04:46:07 -0500 Message-ID: <52931C57.9020901@redhat.com> Date: Mon, 25 Nov 2013 10:45:59 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1383743088-8139-1-git-send-email-quintela@redhat.com> <1383748635.1739.92.camel@nilsson.home.kraxel.org> <527A6510.9080504@redhat.com> <5292F0B7.6040909@linux.vnet.ibm.com> In-Reply-To: <5292F0B7.6040909@linux.vnet.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 00/39] bitmap handling optimization List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael R. Hines" Cc: qemu-devel@nongnu.org, chegu_vinod@hp.com, Gerd Hoffmann , Juan Quintela Il 25/11/2013 07:39, Michael R. Hines ha scritto: >> Because some random option ROM is loaded before the RAM region is >> created, and thus the ram_addr_t's become misaligned. Keeping the >> ram_addr_t's aligned in find_ram_offset is easy: >> >> diff --git a/exec.c b/exec.c >> index 79610ce..1b82e81 100644 >> --- a/exec.c >> +++ b/exec.c >> @@ -1002,7 +1002,7 @@ static ram_addr_t find_ram_offset(ram_addr_t size) >> QTAILQ_FOREACH(block, &ram_list.blocks, next) { >> ram_addr_t end, next = RAM_ADDR_MAX; >> >> - end = block->offset + block->length; >> + end = ROUND_UP(block->offset + block->length, >> TARGET_PAGE_SIZE * 64); >> >> QTAILQ_FOREACH(next_block, &ram_list.blocks, next) { >> if (next_block->offset >= end) { >> >> but I'm not sure if we're allowed to change the ram_addr_t's. On one >> hand they >> are not part of guest ABI, on the other hand RDMA migration uses them >> in the protocol. >> >> Michael, can you check if RDMA migration works from a QEMU *without* >> this patch to one *with*: > > I tested the patch as requested. It doesn't seem to break the migration. > I compiled and looped the migration a couple of times and it runs through. > > Sorry for the late reply. Thanks, no problem since Juan's patch is 1.8 material anyway. Juan, looks like I was wrong about the ram_addr_t being part of the protocol (more likely, it is part of the protocol but it doesn't depend on equal ram_addr_t). You could then add the above one-liner as a separate patch. Paolo