From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nrv4A-0004c4-4y for qemu-devel@nongnu.org; Wed, 17 Mar 2010 11:21:50 -0400 Received: from [199.232.76.173] (port=42552 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nrv49-0004bw-RK for qemu-devel@nongnu.org; Wed, 17 Mar 2010 11:21:49 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nrv49-0007jG-6l for qemu-devel@nongnu.org; Wed, 17 Mar 2010 11:21:49 -0400 Received: from mx20.gnu.org ([199.232.41.8]:4819) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Nrv48-0007j8-TM for qemu-devel@nongnu.org; Wed, 17 Mar 2010 11:21:49 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nrv47-0003pm-Py for qemu-devel@nongnu.org; Wed, 17 Mar 2010 11:21:48 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH QEMU] Transparent Hugepage Support #3 Date: Wed, 17 Mar 2010 15:21:26 +0000 References: <20100317145950.GA5752@random.random> <201003171505.57790.paul@codesourcery.com> <20100317151401.GB5752@random.random> In-Reply-To: <20100317151401.GB5752@random.random> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003171521.26911.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: qemu-devel@nongnu.org, Avi Kivity > On Wed, Mar 17, 2010 at 03:05:57PM +0000, Paul Brook wrote: > > > + if (size >= PREFERRED_RAM_ALIGN) > > > + new_block->host = qemu_memalign(PREFERRED_RAM_ALIGN, > > > size); > > > > Is this deliberately bigger-than rather than multiple-of? > > Having the size not be a multiple of alignment seems somewhat strange, > > it's always going to be wrong at one end... > > 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. > The guest physical address that the host > retval corresponds to, has to be aligned with PREFERRED_RAM_ALIGN for > NPT/EPT to work. I don't think it's a big concern right now. If you allocating chinks that are multiples of the relevant page size, then I don't think you can expect anything particularly sensible to happen. Paul