From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: Debian linux-image-2.6.32-4-xen-amd64
	2.6.32-11	doesn't
	boot with > 4 GiB; resets immediatelly, no log messages
Date: Tue, 20 Apr 2010 11:19:14 -0700
Message-ID: <4BCDF022.5070304@goop.org>
References: <20100408113422.GD4183@kepler.schwinge.homeip.net>
	<20100408133820.GA29832@phenom.dumpdata.com>
	<20100408221953.GG4183@kepler.schwinge.homeip.net>
	<4BBE5DF2.6040707@goop.org>
	<20100409180016.GA14029@kepler.schwinge.homeip.net>
	<4BBF7004.8000707@goop.org>
	<20100410221349.GM4183@kepler.schwinge.homeip.net>
	<4BC1013D.2020003@goop.org>
	<20100420111818.GA4416@kepler.schwinge.homeip.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <20100420111818.GA4416@kepler.schwinge.homeip.net>
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: Thomas Schwinge <thomas@schwinge.name>
Cc: Ian Campbell <ijc@hellion.org.uk>, xen-devel@lists.xensource.com, Keir Fraser <keir.fraser@eu.citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
List-Id: xen-devel@lists.xenproject.org

On 04/20/2010 04:18 AM, Thomas Schwinge wrote:
> Hello!
>
> On Sat, Apr 10, 2010 at 03:52:45PM -0700, Jeremy Fitzhardinge wrote:
>   
>> On 04/10/2010 03:13 PM, Thomas Schwinge wrote:
>>     
>>>> Normally that would be OK, because it uses:
>>>>
>>>> 	__get_user(pfn, &machine_to_phys_mapping[mfn]);
>>>>
>>>> to dereference the array.  But at this early stage, none of the kernel's
>>>> exception handlers have been set up, so this will just fault into Xen.
>>>>
>>>> It would be interesting to confirm this by building your kernel with
>>>> CONFIG_DEBUG_INFO=y in the .config, and verify that the faulting
>>>> instruction is actually this line.
>>>>     
>>>>         
>>> Bingo!
>>>       
>> Excellent.  Now I just need to work out how to do a proper manual limit
>> check on the mfn.  (I've always been a bit suspicious of this code,
>> because there's no guarantee that a random invalid mfn *won't* happen to
>> return the pfn we're looking for...)
>>     
> Any news already about this one?
>
>   

Keir, is there a way to test the validity of an mfn before using it to
index into the m2p array?

    J