[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 06/12] xenpaging: update machine_to_phys_mapping[] during page deallocation


  • To: Olaf Hering <olaf@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxx>
  • Date: Tue, 11 Jan 2011 10:37:08 +0000
  • Cc:
  • Delivery-date: Tue, 11 Jan 2011 03:38:57 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=Y9+G+w7jdDWNzOFjzGrXaweQazbQnNVFsP8J7+4YXbDXs9OAR0WXtIoaKE3JDvSeQ5 5LuodSp27xIKIFnuPw+L7J3G+XfHMplbyCOayBIA14PDoNPTos/8Qolkee+zHGqjJdOD 0bDcfn3jkKbpiiL1DXbtd725hR+A455spFRJg=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acuxe38Aouzk1yl2skOX0Y7QHKuPeQ==
  • Thread-topic: [Xen-devel] [PATCH 06/12] xenpaging: update machine_to_phys_mapping[] during page deallocation

Could we do this in free_heap_pages() instead? That definitely catches
everything that gets placed in Xen's free pool.

 -- Keir

On 10/01/2011 16:43, "Olaf Hering" <olaf@xxxxxxxxx> wrote:

> The machine_to_phys_mapping[] array needs updating during page
> deallocation.  If that page is allocated again, a call to
> get_gpfn_from_mfn() will still return an old gfn from another guest.
> This will cause trouble because this gfn number has no or different
> meaning in the context of the current guest.
> 
> This happens when the entire guest ram is paged-out before
> xen_vga_populate_vram() runs.  Then XENMEM_populate_physmap is called
> with gfn 0xff000.  A new page is allocated with alloc_domheap_pages.
> This new page does not have a gfn yet.  However, in
> guest_physmap_add_entry() the passed mfn maps still to an old gfn
> (perhaps from another old guest).  This old gfn is in paged-out state in
> this guests context and has no mfn anymore.  As a result, the ASSERT()
> triggers because p2m_is_ram() is true for p2m_ram_paging* types.
> If the machine_to_phys_mapping[] array is updated properly, both loops
> in guest_physmap_add_entry() turn into no-ops for the new page and the
> mfn/gfn mapping will be done at the end of the function.
> 
> If XENMEM_add_to_physmap is used with XENMAPSPACE_gmfn,
> get_gpfn_from_mfn() will return an appearently valid gfn.  As a result,
> guest_physmap_remove_page() is called.  The ASSERT in p2m_remove_page
> triggers because the passed mfn does not match the old mfn for the
> passed gfn.
> 
> 
> Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
> 
> ---
>  xen/common/page_alloc.c |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> --- xen-unstable.hg-4.1.22571.orig/xen/common/page_alloc.c
> +++ xen-unstable.hg-4.1.22571/xen/common/page_alloc.c
> @@ -1200,9 +1200,15 @@ void free_domheap_pages(struct page_info
>  {
>      int            i, drop_dom_ref;
>      struct domain *d = page_get_owner(pg);
> +    unsigned long mfn;
>  
>      ASSERT(!in_irq());
>  
> +    /* this page is not a gfn anymore */
> +    mfn = page_to_mfn(pg);
> +    for ( i = 0; i < (1 << order); i++ )
> +        set_gpfn_from_mfn(mfn + i, INVALID_M2P_ENTRY);
> +
>      if ( unlikely(is_xen_heap_page(pg)) )
>      {
>          /* NB. May recursively lock from relinquish_memory(). */
> 
> 
> _______________________________________________
> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.