WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Problem pinning pages from dom0

To: Jacob Gorm Hansen <jacob@xxxxxxxx>
Subject: Re: [Xen-devel] Problem pinning pages from dom0
From: Steven Hand <Steven.Hand@xxxxxxxxxxxx>
Date: Thu, 22 Jan 2004 01:13:35 +0000
Cc: Xen list <xen-devel@xxxxxxxxxxxxxxxxxxxxx>, Steven.Hand@xxxxxxxxxxxx
Delivery-date: Thu, 22 Jan 2004 01:13:36 +0000
Envelope-to: Steven.Hand@xxxxxxxxxxxx
In-reply-to: Message from Jacob Gorm Hansen <jacob@xxxxxxxx> of "Thu, 22 Jan 2004 01:53:20 +0100." <1074732800.1428.7.camel@paleface>
>I am trying to pin some pages (used to work fine), but now I am seeing
>loads of these:
>
>DOM0: (file=memory.c, line=379) Bad L1 page type settings 0100
>DOM0: (file=memory.c, line=379) Bad L1 page type settings 0080
>DOM0: (file=memory.c, line=341) Bad page type for pfn 000090f9
>(20000000)
>DOM0: (file=memory.c, line=779) Error while pinning pfn 000090f9
>
>Any clues as to the character of my offence? (Perhaps this is obvious
>but it is getting a bit late now...)

The first two are produced as sanity checks by get_page_from_l1e(), 
called either when you update a 'leaf' [*] page table entry (your 
case I guess), or when you install a new 'leaf' page table. The 
PTEs in question are 'unsafe' in that they set bits which are not
allowed by the Xen interface (viz. global bit and superpage bit
respectively). 

Given that you're unlikely to be trying to do this on purpose, 
the most probable cause is that your page table is just screwed, 
and the 'leaf' entries in question are actually random bits of 
other memory; easiest way to check this is to print out the entire
32-bit value in memory.c and see if it looks at all plausible (viz.
looks like a mapping for some piece of VAS you know about). 

This would also explain the third message which should never really
happen unless your dealing with bogus page structures; turn on 
DPRINTK() in include/xeno/mm.h:get_page_type() for more info about
what's really going wron ghere. 

The last is effectively the same as the third, just triggered from 
a different point. 

Hope this is of some use, 

cheers, 

S.



<Prev in Thread] Current Thread [Next in Thread>