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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

Whoever drops the last reference calls free_domheap_pages(). The fact that
dom1 is taking that path is pretty strong evidence that the general count is
screwed (hasn't been incremented enough). Reference counting in shadow mode
is Tim Deegan's area.

 -- Keir

On 12/10/07 23:49, "Roger Cruz" <rcruz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

> One additional question I forgot to ask in my previous posting is why
> domain 1, which does not own the page being freed is allowed to make the
> deletion in free_domheap_pages.  Shouldn't only the page owners be the
> ones that can free their own pages or does the lack of a check is needed
> for domain 0 to create and delete domains?
> 
> R.
> 
> 
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Roger Cruz
> Sent: Friday, October 12, 2007 3:16 PM
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] Question on type_info and count_info for a
> page_infostructure.
> 
> 
> 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
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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