From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrea Arcangeli <andrea@qumranet.com>
Subject: Re: [PATCH] Handle vma regions with no backing page
Date: Wed, 4 Jun 2008 21:51:35 +0200
Message-ID: <20080604195135.GP21613@duo.random>
References: <alpine.DEB.1.10.0806031413010.8803@cluwyn.haifa.ibm.com> <20080603113937.GE8158@duo.random> <1212592164.26322.10.camel@lnx-benami> <20080604161755.GC7089@il.ibm.com> <20080604193402.GO21613@duo.random> <4846EFE0.5090304@codemonkey.ws>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Muli Ben-Yehuda <muli@il.ibm.com>,
	Ben-Ami Yassour1 <BENAMI@il.ibm.com>,
	Han Weidong <weidong.han@intel.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	Amit Shah <amit.shah@qumranet.com>, kvm@vger.kernel.org,
	avi@qumranet.com, Dave Hansen <haveblue@us.ibm.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Return-path: <kvm-owner@vger.kernel.org>
Received: from host36-195-149-62.serverdedicati.aruba.it ([62.149.195.36]:59363
	"EHLO mx.cpushare.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753341AbYFDTvh (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 4 Jun 2008 15:51:37 -0400
Content-Disposition: inline
In-Reply-To: <4846EFE0.5090304@codemonkey.ws>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Wed, Jun 04, 2008 at 02:41:20PM -0500, Anthony Liguori wrote:
> The pfn does have a backing page.  When using CONFIG_FLATMEM, pfn_valid() 
> is simply:
>
> #ifdef CONFIG_FLATMEM
> #define pfn_valid(pfn)          ((pfn) < end_pfn)
> #endif
>
> And this is true, pfn_valid() just indicates whether there is a space in 
> mem_map[], and there certainly is.  Note this only happens when there is a 
> valid PFN that's greater than the PCI memory (using 4GB+ of memory).

So everything is fine with pfn_valid. The check against end_pfn with
flatmem is what I also the one I've looked while doing the
reserved-ram patch.

pfn_valid must only signal if pfn_to_page(pfn) returns garbage or a
struct page (you can't call pfn_to_page if pfn_valid is 0). That's all.

> Dave mentioned that SetPageReserved() doesn't necessarily get called for 
> zones with bad alignment.

What does 'bad alignment' mean? Buddy was used to require each zone to
start at 1<<MAX_ORDER naturally aligned physical address (any ram
before the alignment was wasted). In any case all 'struct page' where
pfn_valid would return true, should start with PG_reserved set, if
it's not the case it should be fixed I guess.