Our user code in the Windows HVM requests that the grant map reference
be mapped as R+W.
I found out how the type info counter is getting incremented. The way
I implemented the grant table mapping for an HVM is like this. On the
grantee side, use the PFN specified to remove the
originally-domain-assigned MFN from the P2M table of the grantee (using
guest_remove_page). Once removed, I then use guest_physmap_add_page()
to add the newly granted MFN to its P2M entry.
The problem with this approach is that guest_remove_page eventually
calls shadow_blow_tables which goes through blowing away each P2M entry.
When it hits one of those grant-mapped entries, that's where the
increment takes place. Specifically in the routine put_page_from_l1e()
where this piece of code fails to decrement the type info because the
owner of the page (e), does not match the one calling the routine (d).
if ( (l1e_get_flags(l1e) & _PAGE_RW) &&
!(unlikely((e != d) && paging_mode_external(e))) )
{
put_page_and_type(page);
}
else
{
....
put_page(page);
}
I tried to get around this check for our purposes and changed the IF
conditional to:
if ( (l1e_get_flags(l1e) & _PAGE_RW) &&
paging_mode_external(e))
{
put_page_and_type(page);
}
else
{
....
put_page(page);
}
But that caused a lot more problems which are beyond my comprehension
and abundance of time to solve right now. I'll have to come back to
this problem later on but if you have any suggestions, I'm all ears.
Thanks
R.
Ps. This is the call sequence for a grant table mapping in the HVM.
(XEN) Xen call trace:
(XEN) [<ff12a7cb>] put_page_from_l1e+0x31b/0x4f0
(XEN) [<ff16dee2>] sh_destroy_l1_shadow__shadow_3_guest_3+0x182/0x240
(XEN) [<ff170230>] shadow_set_l2e+0x300/0x380
(XEN) [<ff17070c>] sh_unhook_pae_mappings__shadow_3_guest_3+0x9c/0xd0
(XEN) [<ff166ad6>] shadow_blow_tables+0x116/0x190
(XEN) [<ff1674a9>] shadow_write_p2m_entry+0xd9/0x320
(XEN) [<ff16309a>] set_p2m_entry+0x15a/0x1e0
(XEN) [<ff1632c4>] p2m_remove_page+0x34/0x70
(XEN) [<ff16363a>] guest_physmap_remove_page+0x5a/0xb0
(XEN) [<ff10c6d9>] guest_remove_page+0xe9/0x620
(XEN) [<ff12cd2b>] create_grant_host_mapping+0x84b/0xb80
(XEN) [<ff108d16>] do_grant_table_op+0x4a6/0x1ad0
(XEN) [<ff1416e2>] hvm_do_hypercall+0xb2/0x1e0
(XEN) [<ff160665>] vmx_vmexit_handler+0x305/0x1680
(XEN) [<ff1619f7>] vmx_asm_vmexit_handler+0x17/0x20
-----Original Message-----
From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxxxxx]
Sent: Monday, October 15, 2007 4:45 AM
To: Roger Cruz
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: 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
|
Home