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

[Xen-devel] Question on type_info and count_info for a page_info structu

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Question on type_info and count_info for a page_info structure.
From: "Roger Cruz" <rcruz@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 12 Oct 2007 15:16:24 -0400
Delivery-date: Fri, 12 Oct 2007 12:17:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1192182958.9767.18.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcgMte75NJJnYNaARPqTrE/RSfE48QATKGlw
Thread-topic: Question on type_info and count_info for a page_info structure.
I'm trying to debug a problem where a page is being freed via the
free_domheap_pages() routine and it is triggering a bug check for this
condition:

            BUG_ON((pg[i].u.inuse.type_info & PGT_count_mask) != 0);

I have printed the page_info fields for type_info and it shows large
numbers there with the count_info equals to 0.

(XEN) page_alloc.c:902: pg=0xf869f570, i=0x0, type_info = 0xe800005d,
count info = 0x0, domid=0x2 order=0x0

I found the spot where type_info is incremented (get_page_type).  The
routine is getting called due to a page fault:

         [<ff12889c>] get_page_type+0x16c/0x460
(XEN)    [<ff127f77>] get_page_from_l1e+0x187/0x430
(XEN)    [<ff169d49>] shadow_set_l1e+0xe9/0x1d0
(XEN)    [<ff16baf9>] sh_page_fault__shadow_3_guest_3+0x3f9/0xf80
(XEN)    [<ff15c076>] vmx_vmexit_handler+0x786/0x1680
(XEN)    [<ff15cf87>] vmx_asm_vmexit_handler+0x17/0x20

At this point, you need a little background info.  The page in question
belongs to HVM domain 2 and have modified the hypervisor to allow me to
map it (via grant_table) into another HVM (domain 1).  Domain 1 is the
one causing the crash as it tries to unmap the previously mapped
grant_table reference.

(XEN) Xen call trace:
(XEN)    [<ff10e465>] free_domheap_pages+0xb5/0x310
(XEN)    [<ff10963d>] do_grant_table_op+0x196d/0x1ae0
(XEN)    [<ff13de32>] hvm_do_hypercall+0xb2/0x1e0
(XEN)    [<ff15ba95>] vmx_vmexit_handler+0x305/0x1680
(XEN)    [<ff15ce27>] vmx_asm_vmexit_handler+0x17/0x20

So I can state that the page is mapped correctly and useable and as it
is accessed, it incurs page faults which increment the type_info count
but don't appear to increment count_info.  This confused me because my
understanding of these counters is that they would track each other.
Any clarification on their uses is extremely appreciated.

Thank you
Roger

PS.  This is from XenSource's 3.1.0 hypervisor

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel