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-ia64-devel

Re: [Xen-ia64-devel] [Patch][RFC] Avoid to domain_put_page pte of INVALI

To: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [Patch][RFC] Avoid to domain_put_page pte of INVALID_M2P_ENTRY
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Fri, 25 Apr 2008 20:22:31 +0900
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 25 Apr 2008 04:22:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <76C8A5DD2DE05Ftakebe_akio@xxxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <62C8A4FE1CF83Ftakebe_akio@xxxxxxxxxxxxxx> <20080424065547.GL13448%yamahata@xxxxxxxxxxxxx> <76C8A5DD2DE05Ftakebe_akio@xxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6i
On Thu, Apr 24, 2008 at 04:31:15PM +0900, Akio Takebe wrote:

> >Let me look into it.
> >Your stack trace didn't say about what grant table operation.
> >It should GNTTABOP_unmap_grant_ref or GNTTABOP_unmap_and_replace.
> >Do you know which it is?
> Thank you for you investigating.
> Both of them called GNTTABOP_unmap_and_replace.

Could you try this patch?

# HG changeset patch
# User Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
# Date 1209122032 -32400
# Node ID 87336b949907499cf095fc2a98cab3e4fd8524a6
# Parent  3dc44790c7ec04d8229ceca698a94ad6346f1106
[IA64] fix GNTTABOP_replace_and_unmap

This patch fixes the following xen panic repored by Akio Takebe.
> When we tested network between domU <-> dom0 with FTP load tools,
> we hitted BUG() in hypervisor. It is always reproducible for a few minutes.
> At that time, we got the following message.
> vmi15.sky.yk.fujitsu.co.jp login: (XEN) Xen BUG at mm.c:1254
>
> (XEN) FIXME: implement ia64 dump_execution_state()
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Xen BUG at mm.c:1254
> (XEN) ****************************************
> (XEN)
> (XEN) Manual reset required ('noreboot' specified)
> (XEN) machine_halt called.  spinning...

GNTTABOP_replace_and_unmap must updates both the p2m table and m2p
table. However the m2p table update was missing so that
the above BUG_ON() was triggered detecting the inconsistency
between the p2m table and the m2p table.
This patch adds the missing the m2p table updates.
This patch also fixes the error path of the function. It may
return before completing the page table manipulation.

Signed-off-by: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>

diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -2187,6 +2187,7 @@
     struct page_info* page = mfn_to_page(mfn);
     struct page_info* new_page = NULL;
     volatile pte_t* new_page_pte = NULL;
+    unsigned long new_page_mfn;
 
     if (new_gpaddr) {
         new_page_pte = lookup_noalloc_domain_pte_none(d, new_gpaddr);
@@ -2194,7 +2195,6 @@
             new_pte = ptep_get_and_clear(&d->arch.mm,
                                          new_gpaddr, new_page_pte);
             if (likely(pte_present(new_pte))) {
-                unsigned long new_page_mfn;
                 struct domain* page_owner;
 
                 new_page_mfn = pte_pfn(new_pte);
@@ -2255,22 +2255,24 @@
         goto out;
     }
 
+    if (new_page) {
+        set_gpfn_from_mfn(new_page_mfn, gpfn);
+        /* smp_mb() isn't needed because assign_domain_pge_cmpxchg_rel()
+           has release semantics. */
+    }
     old_pte = ptep_cmpxchg_rel(&d->arch.mm, gpaddr, pte, cur_pte, new_pte);
-    if (unlikely(!pte_present(old_pte))) {
-        gdprintk(XENLOG_INFO, "%s: gpaddr 0x%lx mfn 0x%lx"
-                         " cur_pte 0x%lx old_pte 0x%lx\n",
-                __func__, gpaddr, mfn, pte_val(cur_pte), pte_val(old_pte));
-        goto out;
-    }
     if (unlikely(pte_val(cur_pte) != pte_val(old_pte))) {
         if (pte_pfn(old_pte) == mfn) {
             goto again;
         }
-        gdprintk(XENLOG_INFO, "%s gpaddr 0x%lx mfn 0x%lx cur_pte "
-                "0x%lx old_pte 0x%lx\n",
-                __func__, gpaddr, mfn, pte_val(cur_pte), pte_val(old_pte));
+        if (new_page) {
+            set_gpfn_from_mfn(new_page_mfn, INVALID_M2P_ENTRY);
+            domain_put_page(d, new_gpaddr, new_page_pte, new_pte, 1);
+        }
         goto out;
     }
+    if (unlikely(!pte_present(old_pte)))
+        goto out;
     BUG_ON(pte_pfn(old_pte) != mfn);
 
     /* try_to_clear_PGC_allocate(d, page) is not needed. */
@@ -2283,8 +2285,9 @@
     return GNTST_okay;
 
  out:
-    if (new_page)
-        domain_put_page(d, new_gpaddr, new_page_pte, new_pte, 1);
+    gdprintk(XENLOG_INFO, "%s gpaddr 0x%lx mfn 0x%lx cur_pte "
+             "0x%lx old_pte 0x%lx\n",
+             __func__, gpaddr, mfn, pte_val(cur_pte), pte_val(old_pte));
     return GNTST_general_error;
 }
 


-- 
yamahata

Attachment: 17527_87336b949907.patch
Description: Text Data

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel