From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: tracking of Xen heap pages shared with guest Date: Fri, 14 Mar 2008 12:59:35 +0000 Message-ID: <47DA84C7.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org I assume I'm overlooking something, but can someone explain how page tracking works in the following two cases: a) A guest unintentionally or maliciously frees (e.g. through decrease_reservation) a page shared from the Xen heap (e.g. the shared info page). From what I can see, such a page would have a reference count of 1 (from share_xen_page_with_guest(), assuming the guest doesn't have the page mapped), and would hence be immediately freed with the corresponding put_page(). Nevertheless Xen itself may continue to write to such a page. b) A domU that had a xenoprof buffer allocated gets killed. Since the xenoprof code directly calls free_xenheap_pages() on the buffer, any mapping dom0 may have to it would not be considered, and hence dom0 would retain a mapping to free memory. Additionally, the put_page() in unshare_xenoprof_page_with_guest() could revert the singe reference to the page established through share_xen_page_with_guest() (i.e. if dom0 never mapped or already unmapped the buffer), which again would result in the buffer getting freed (and thus d->xenoprof->rawbuf becoming stale). Apparently I'm just failing to find the places where extra reference counts are being established for such pages... Thanks, Jan