From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QI0Kh-0007uh-0a for qemu-devel@nongnu.org; Thu, 05 May 2011 11:19:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QI0Kg-0004uJ-0C for qemu-devel@nongnu.org; Thu, 05 May 2011 11:19:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27960) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QI0Kf-0004uC-Ki for qemu-devel@nongnu.org; Thu, 05 May 2011 11:19:13 -0400 Date: Thu, 5 May 2011 18:18:59 +0300 From: "Michael S. Tsirkin" Message-ID: <20110505151859.GA1915@redhat.com> References: <20110503182039.28430.26530.stgit@s20.home> <20110503183652.28430.83897.stgit@s20.home> <20110505132106.GG30119@redhat.com> <1304605266.3081.5.camel@x201> <4DC2B4A1.6030204@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DC2B4A1.6030204@redhat.com> 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: Jes Sorensen Cc: jan.kiszka@siemens.com, Alex Williamson , qemu-devel@nongnu.org, armbru@redhat.com On Thu, May 05, 2011 at 04:30:57PM +0200, Jes Sorensen wrote: > 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. For example, a 4G size does not fit in 32 bits. > It seems fair to use it for the size here. > > Acked-by: Jes Sorensen >