From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1JKt6F-00025A-BI
	for qemu-devel@nongnu.org; Fri, 01 Feb 2008 05:26:23 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1JKt6E-00024W-3E
	for qemu-devel@nongnu.org; Fri, 01 Feb 2008 05:26:22 -0500
Received: from mx1.polytechnique.org ([129.104.30.34])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <fabrice@bellard.org>) id 1JKt6D-0005C5-I4
	for qemu-devel@nongnu.org; Fri, 01 Feb 2008 05:26:21 -0500
Message-ID: <47A2F3C7.6060409@bellard.org>
Date: Fri, 01 Feb 2008 11:26:15 +0100
From: Fabrice Bellard <fabrice@bellard.org>
MIME-Version: 1.0
References: <1201818980-27534-1-git-send-email-aliguori@us.ibm.com>
	<1201818980-27534-2-git-send-email-aliguori@us.ibm.com>
In-Reply-To: <1201818980-27534-2-git-send-email-aliguori@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G
	support
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org, Paul Brook <paul@codesourcery.com>

Anthony Liguori wrote:
> KVM supports more than 2GB of memory for x86_64 hosts.  The following patch
> fixes a number of type related issues where int's were being used when they
> shouldn't have been.  It also introduces CMOS support so the BIOS can build
> the appropriate e820 tables.

 > [...]
> +    /* above 4giga memory allocation */
> +    if (above_4g_mem_size > 0) {
> +        ram_addr = qemu_ram_alloc(above_4g_mem_size);
> +        cpu_register_physical_memory(0x100000000, above_4g_mem_size, ram_addr);
> +    }
> +

Why do you need this ? All the RAM can be registered with a single call. 
  I fear you need to do that because of KVM RAM handling limitations.

> Index: qemu/osdep.c
> ===================================================================
> --- qemu.orig/osdep.c	2008-01-30 13:47:00.000000000 -0600
> +++ qemu/osdep.c	2008-01-30 13:47:31.000000000 -0600
> @@ -113,7 +113,7 @@
>              int64_t free_space;
>              int ram_mb;
>  
> -            extern int ram_size;
> +            extern int64_t ram_size;
>              free_space = (int64_t)stfs.f_bavail * stfs.f_bsize;
>              if ((ram_size + 8192 * 1024) >= free_space) {
>                  ram_mb = (ram_size / (1024 * 1024));
> @@ -202,7 +202,7 @@
>  #ifdef _BSD
>      return valloc(size);
>  #else
> -    return memalign(4096, size);
> +    return memalign(TARGET_PAGE_SIZE, size);
>  #endif
>  }

No fully correct because it is intended to be the host page size.

> +extern int64_t ram_size;

I agree with the fact that ram_size should be 64 bit. Maybe each machine 
could test the value and emit an error message if it is too big. Maybe 
an uint64_t would be better though.

Fabrice.