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

[Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>]

Hi,

At 11:02 -0400 on 16 Oct (1192532534), Roger Cruz wrote:
> 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).

The intent of that "e != d" test is that foreign mappings of HVM
domains' pages should not take type counts.  (The rationale is that when
we shadow a page we need to be able to remove all the writable mappings
that the guest has of it.  The only way we know if we've succeeded is
when the type-count falls to zero; so if e.g. qemu in dom0 has a
writable mapping, we can never reduce the type count to zero by making
changes in the shadows -- we'd need to be able to find qemu's mapping,
and we don't even know which domain that's in.)

So when we remove the shadow entry that points at the foreign (granted)
frame, the put_page_from_l1e() called from the shadow code is not
dropping the type count.  I don't understand where the type count comes
from, though, since the shadow code used get_page_from_l1e() when it put
the entry there in the first place, and that has the same behaviour.

Are you setting shadow pagetable entries directly in the grant code?

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