From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KdnNz-0000B7-6k
	for qemu-devel@nongnu.org; Thu, 11 Sep 2008 10:43:07 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KdnNx-000096-Js
	for qemu-devel@nongnu.org; Thu, 11 Sep 2008 10:43:06 -0400
Received: from [199.232.76.173] (port=51890 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KdnNx-00008a-AM
	for qemu-devel@nongnu.org; Thu, 11 Sep 2008 10:43:05 -0400
Received: from mx2.redhat.com ([66.187.237.31]:53230)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <glommer@redhat.com>) id 1KdnNw-0007wj-Ov
	for qemu-devel@nongnu.org; Thu, 11 Sep 2008 10:43:05 -0400
Date: Thu, 11 Sep 2008 11:42:03 -0300
From: Glauber Costa <glommer@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] split memory allocation
Message-ID: <20080911144203.GB24285@poweredge.glommer>
References: <1221140541-24464-1-git-send-email-glommer@redhat.com>
	<48C928AF.1070208@aurel32.net> <48C92CC0.8030606@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <48C92CC0.8030606@codemonkey.ws>
Content-Transfer-Encoding: quoted-printable
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 <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org

On Thu, Sep 11, 2008 at 09:35:44AM -0500, Anthony Liguori wrote:
> Aurelien Jarno wrote:
>> Glauber Costa a =E9crit :
>>  =20
>>> 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 splitin=
g
>>> raw qemu.
>>>
>>> Signed-off-by: Glauber Costa <glommer@redhat.com>
>>> ---
>>>  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 v=
ga_ram_size,
>>>      vmport_init();
>>>       /* allocate RAM */
>>> -    ram_addr =3D qemu_ram_alloc(ram_size);
>>> -    cpu_register_physical_memory(0, below_4g_mem_size, ram_addr);
>>> +    ram_addr =3D qemu_ram_alloc(0xa0000);
>>> +    cpu_register_physical_memory(0, 0xa0000, ram_addr);
>>> +
>>> +    ram_addr =3D qemu_ram_alloc(0x100000 - 0xa0000);   /* hole */
>>>    =20
>>
>> What the point of allocating RAM for the memory hole if it is not mapp=
ed?
>>  =20
>
> If you don't, you violate the phys_ram_base + PA assumption for all of =
=20
> memory.  No code should rely on this but practically speaking, there is=
 =20
> still some code in QEMU that does.
>
> Since the RAM is never touched, it doesn't actually impact the RSS size=
 =20
> so it's not all that important.
>
> Regards,
>
> Anthony Liguori
>
Precisely.

We actually saw this a while ago. the kernel loader was broken due to tha=
t.