From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NrvZB-0001ty-3w
	for qemu-devel@nongnu.org; Wed, 17 Mar 2010 11:53:53 -0400
Received: from [199.232.76.173] (port=45440 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NrvZA-0001tm-F6
	for qemu-devel@nongnu.org; Wed, 17 Mar 2010 11:53:52 -0400
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <paul@codesourcery.com>) id 1NrvZ9-0000kp-Dl
	for qemu-devel@nongnu.org; Wed, 17 Mar 2010 11:53:52 -0400
Received: from mx20.gnu.org ([199.232.41.8]:5248)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1NrvZ9-0000iH-2M
	for qemu-devel@nongnu.org; Wed, 17 Mar 2010 11:53:51 -0400
Received: from mail.codesourcery.com ([38.113.113.100])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1NrvXw-0004aG-E5
	for qemu-devel@nongnu.org; Wed, 17 Mar 2010 11:52:36 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH QEMU] Transparent Hugepage Support #3
Date: Wed, 17 Mar 2010 15:52:15 +0000
References: <20100317145950.GA5752@random.random>
	<201003171521.26911.paul@codesourcery.com>
	<20100317153522.GC5752@random.random>
In-Reply-To: <20100317153522.GC5752@random.random>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201003171552.15230.paul@codesourcery.com>
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: qemu-devel@nongnu.org
Cc: Andrea Arcangeli <aarcange@redhat.com>, Avi Kivity <avi@redhat.com>

> > > Size not multiple I think is legitimate, the below-4G chunk isn't
> > > required to end 2M aligned, all it matters is that the above-4G then
> > > starts aligned. In short one thing to add in the future as parameter
> > > to qemu_ram_alloc is the physical address that the host virtual
> > > address corresponds to.
> >
> > In general you don't know this at allocation time.
> 
> Caller knows it, it's not like the caller is outside of qemu, it's not
> some library. We know this is enough with the caller that there is now.

No we don't.  As discussed previously, there are machines where the physical 
location of RAM is configurable at runtime.  In fact it's common for the ram 
to be completely absent at reset.

Paul