[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Question on type_info and count_info for a page_info structure.



Hi,

At 15:16 -0400 on 12 Oct (1192202184), Roger Cruz wrote:
> 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

OK, so this page has a type-count of 93! I'd guess that not only is
there a point where a count_info+type_info increment is matched by a
count_info-only decrement, but it's happened quite a few times before
you've tripped over it. :(

> 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

Seems reasonable.  The shadow code has mapped the page for the guest,
with type PGT_writeable_page, matching up with the guest's pagetable
contents.

> 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

That's a grant mapping being pulled down.  Can you find out from the
symbols in your build whether this is a read-only or read-write mapping
being pulled down?

> 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. 

I very much doubt it.  get_page_from_l1e() uses get_page_and_type(),
which increments the count_info first, then the type_info.

Can you trace the grant mappings that you've introduced and check
whether the grants are being introduced as read-write and removed as
read-only?

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, XenSource UK Limited
Registered office c/o EC2Y 5EB, UK; company number 05334508

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.