From mboxrd@z Thu Jan  1 00:00:00 1970
From: Olaf Hering <olaf@aepfle.de>
Subject: odd gfn number checking in p2m.c
Date: Sun, 19 Sep 2010 17:49:03 +0200
Message-ID: <20100919154903.GA32635@aepfle.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Return-path: <xen-devel-bounces@lists.xensource.com>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: xen-devel@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org


Hello,

how can a gfn become 0x555555 as checked in
p2m.c:guest_physmap_add_entry() and p2m_alloc_table()?
Looking further in p2m.c, audit_p2m() checks only for a 32bit value.

So where is that magic number set, and why is it not a define to
simplify grepping for users of that value?

Olaf