From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHzax-00066I-Jg for qemu-devel@nongnu.org; Thu, 05 May 2011 10:32:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QHzat-0002mC-1p for qemu-devel@nongnu.org; Thu, 05 May 2011 10:31:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57157) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHzas-0002m2-R9 for qemu-devel@nongnu.org; Thu, 05 May 2011 10:31:55 -0400 Message-ID: <4DC2B4A1.6030204@redhat.com> Date: Thu, 05 May 2011 16:30:57 +0200 From: Jes Sorensen MIME-Version: 1.0 References: <20110503182039.28430.26530.stgit@s20.home> <20110503183652.28430.83897.stgit@s20.home> <20110505132106.GG30119@redhat.com> <1304605266.3081.5.camel@x201> In-Reply-To: <1304605266.3081.5.camel@x201> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 3/3] CPUPhysMemoryClient: Batch contiguous addresses when playing catchup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: jan.kiszka@siemens.com, qemu-devel@nongnu.org, armbru@redhat.com, "Michael S. Tsirkin" On 05/05/11 16:21, Alex Williamson wrote: >> > A bit worried that ram_addr_t size might thinkably overflow >> > (it's just a long, could be a 4G ram). Break it out when it fills up? > struct CPUPhysMemoryClient { > void (*set_memory)(struct CPUPhysMemoryClient *client, > target_phys_addr_t start_addr, > ram_addr_t size, > ram_addr_t phys_offset); > > ram_addr_t seems to be the standard for describing these types of > things. It's an unsigned long, so 4G is only concern for 32b builds, > which don't support that much memory anyway. Please apply. Thanks, A memory size can obviously not be bigger than the maximum physical address, so I find it really hard to see how this could overflow. It seems fair to use it for the size here. Acked-by: Jes Sorensen