From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KdnP6-0001iP-MK for qemu-devel@nongnu.org; Thu, 11 Sep 2008 10:44:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KdnP5-0001gb-L8 for qemu-devel@nongnu.org; Thu, 11 Sep 2008 10:44:16 -0400 Received: from [199.232.76.173] (port=51947 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdnP5-0001gG-Bv for qemu-devel@nongnu.org; Thu, 11 Sep 2008 10:44:15 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]:44320) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KdnP4-0008E7-Uu for qemu-devel@nongnu.org; Thu, 11 Sep 2008 10:44:15 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8BEi8EH011759 for ; Thu, 11 Sep 2008 10:44:08 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8BEi8Qe166452 for ; Thu, 11 Sep 2008 10:44:08 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8BEi87B012339 for ; Thu, 11 Sep 2008 10:44:08 -0400 Message-ID: <48C92E87.3080505@us.ibm.com> Date: Thu, 11 Sep 2008 09:43:19 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1221140541-24464-1-git-send-email-glommer@redhat.com> In-Reply-To: <1221140541-24464-1-git-send-email-glommer@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Glauber Costa Cc: qemu-devel@nongnu.org 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. 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); > >