From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50942 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNee6-0001jR-GY for qemu-devel@nongnu.org; Tue, 30 Nov 2010 23:50:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNQWB-00037p-0X for qemu-devel@nongnu.org; Tue, 30 Nov 2010 08:45:15 -0500 Received: from mail-qw0-f45.google.com ([209.85.216.45]:59580) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNQWA-0002yb-UN for qemu-devel@nongnu.org; Tue, 30 Nov 2010 08:45:14 -0500 Received: by qwd7 with SMTP id 7so346712qwd.4 for ; Tue, 30 Nov 2010 05:45:10 -0800 (PST) Message-ID: <4CF4FFC4.9070209@codemonkey.ws> Date: Tue, 30 Nov 2010 07:44:36 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <24346c6699fced39ed3725938091984ed23f48e5.1290552026.git.quintela@redhat.com> <4CF45C0C.705@codemonkey.ws> <4CF4A5EB.2070106@redhat.com> In-Reply-To: <4CF4A5EB.2070106@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 07/10] ram_save_remaining() returns an uint64_t List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Juan Quintela , qemu-devel@nongnu.org, Juan Quintela On 11/30/2010 01:21 AM, Paolo Bonzini wrote: > On 11/30/2010 03:06 AM, Anthony Liguori wrote: >>> >>> -static ram_addr_t ram_save_remaining(void) >>> +static uint64_t ram_save_remaining(void) >>> { >>> RAMBlock *block; >>> - ram_addr_t count = 0; >>> + uint64_t count = 0; >>> >>> QLIST_FOREACH(block,&ram_list.blocks, next) { >>> ram_addr_t addr; >> >> No, it returns a count of bytes of ram which is a subset of ram_addr_t's >> space. The unit is definitely right here. > > It returns a count of pages, actually, which is a different unit. Page size is just a fixed number in the ram_addr_t space. Regards, Anthony Liguori > For example, in practice it can fit in 32 bits even (though I'm not > saying we should make it uint32_t; we'd be dangerously close to the > limit for the guest sizes that Juan is handling). > > Paolo