From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kdnj6-0003Yq-JY for qemu-devel@nongnu.org; Thu, 11 Sep 2008 11:04:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kdnj3-0003YU-2q for qemu-devel@nongnu.org; Thu, 11 Sep 2008 11:04:55 -0400 Received: from [199.232.76.173] (port=39777 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kdnj2-0003YR-Th for qemu-devel@nongnu.org; Thu, 11 Sep 2008 11:04:52 -0400 Received: from mx2.redhat.com ([66.187.237.31]:44166) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kdnj2-0005Bq-BQ for qemu-devel@nongnu.org; Thu, 11 Sep 2008 11:04:52 -0400 Date: Thu, 11 Sep 2008 12:03:57 -0300 From: Glauber Costa Message-ID: <20080911150357.GC24285@poweredge.glommer> References: <1221140541-24464-1-git-send-email-glommer@redhat.com> <48C92E87.3080505@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48C92E87.3080505@us.ibm.com> Subject: [Qemu-devel] Re: [PATCH] split memory allocation Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On Thu, Sep 11, 2008 at 09:43:19AM -0500, Anthony Liguori wrote: > Glauber Costa wrote: >> Right now, kvm keeps the memory allocation split, so we can >> handle different areas in different ways. This schema works with qemu >> too, so it appears to be the common ground. >> >> This patch proposes using this common ground for everyone, by spliting >> raw qemu. >> >> Signed-off-by: Glauber Costa >> --- >> hw/pc.c | 16 ++++++++++++---- >> 1 files changed, 12 insertions(+), 4 deletions(-) >> >> diff --git a/hw/pc.c b/hw/pc.c >> index 435c7d4..d6084ee 100644 >> --- a/hw/pc.c >> +++ b/hw/pc.c >> @@ -777,16 +777,24 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size, >> vmport_init(); >> >> /* allocate RAM */ >> - ram_addr = qemu_ram_alloc(ram_size); >> - cpu_register_physical_memory(0, below_4g_mem_size, ram_addr); >> + ram_addr = qemu_ram_alloc(0xa0000); >> + cpu_register_physical_memory(0, 0xa0000, ram_addr); >> + >> + ram_addr = qemu_ram_alloc(0x100000 - 0xa0000); /* hole */ >> > > It's not really a hole. QEMU leaves a hole from 0xa0000 to 0xc0000 > because this is the VGA area. KVM remaps this range to normal RAM when > the guest sets the VGA card to have a linear framebuffer as an > optimization. > > Later, 0xc0000 to 0xd0000 gets registered as ROM (because it's the VGA > BIOS), and 0xd0000 to about 0xe0000 is option ROM space, and 0xe0000 to > 0x100000 is where the BIOS gets mapped. > > So the comment code be improved to explain what goes in this region and > why we need to allocate ram for it in the first place. > 150 % in agreement. Wait for a new one. > Regards, > > Anthony Liguori > >> + ram_addr = qemu_ram_alloc(below_4g_mem_size - 0x100000); >> + cpu_register_physical_memory(0x100000, >> + below_4g_mem_size - 0x100000, >> + ram_addr); >> >> /* above 4giga memory allocation */ >> if (above_4g_mem_size > 0) { >> - cpu_register_physical_memory((target_phys_addr_t) 0x100000000ULL, >> + ram_addr = qemu_ram_alloc(above_4g_mem_size); >> + cpu_register_physical_memory(0x100000000ULL, >> above_4g_mem_size, >> - ram_addr + below_4g_mem_size); >> + ram_addr); >> } >> >> + >> /* allocate VGA RAM */ >> vga_ram_addr = qemu_ram_alloc(vga_ram_size); >> >> >