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

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

To: Roger Cruz <rcruz@xxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Question on type_info and count_info for a page_info structure.
From: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Date: Tue, 16 Oct 2007 17:10:11 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 16 Oct 2007 09:13:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <40B551BEDC7945419A5897958AB3947C1C918E@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
References: <20071015084513.GA5268@xxxxxxxxxxxxxxxxxxxxx> <40B551BEDC7945419A5897958AB3947C1C918E@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)
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