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.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
