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] [Q] about assign_domain_page_replace

To: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [Q] about assign_domain_page_replace
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Tue, 5 Jun 2007 21:53:51 +0900
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 05 Jun 2007 05:52:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <3DC7A768CD047Ftakebe_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: <3DC7A768CD047Ftakebe_akio@xxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Tue, Jun 05, 2007 at 08:58:16PM +0900, Akio Takebe wrote:

> Is the following patch right?
> 
> diff -r aee991c7723a xen/arch/ia64/xen/mm.c
> --- a/xen/arch/ia64/xen/mm.c    Wed May 09 16:34:47 2007 +0100
> +++ b/xen/arch/ia64/xen/mm.c    Wed Jun 06 05:41:15 2007 +0900
> @@ -1121,7 +1121,7 @@ assign_domain_page_replace(struct domain
>      if (pte_mem(old_pte)) {
>          unsigned long old_mfn = pte_pfn(old_pte);
>  
> -        // mfn = old_mfn case can happen when domain maps a granted page
> +        // mfn != old_mfn case can happen when domain maps a granted page
>          // twice with the same pseudo physial address.
>          // It's non sense, but allowed.
>          // __gnttab_map_grant_ref()
> 

No. 
It describes that "mfn == old_mfn" case can happen in theory.
In that case, domain_put_page() shouldn't called.
Probably my english is broken so that english refinement is necessary.


> If so, I have one more question.
> When assign_domain_page_replace() is called from __dom0vp_add_physmap(),
> there are a case of mfn != old_mfn.
> Is that correct case or a bug?
> At that time, old_mfn->count_info=0.

"mfn != old_mfn" itself isn't a bug of Xen VMM.
It should be okay from the hypervisor point of view.
In both case (== and !=), Xen VMM should continue to work finely.
domain_put_page() makes mfn_to_page(old_mfn)->count_info = 0 and
frees the page.

On the other hand, "pte_mem(old_pte) == true" is a bad sign
from the dom0 point of view. (the current domain is dom0, right?)
domain shouldn't assign new page to pseudo physicall address
which page is already assigned to. I.e. usually pte_mem(old_pte) is false.
Dom0 seems to work badly.


> So if I destroy the domain, hypervisor panic like the below.
> 
> (XEN) Xen BUG at mm.c:233
> (XEN) FIXME: implement ia64 dump_execution_state() 
> (XEN) **************************************** 
> (XEN) Panic on CPU 1: 
> (XEN) Xen BUG at mm.c:233                      
> (XEN) **************************************** 
> (XEN)                                          
> (XEN) Reboot in five seconds...

mm.c:233 isn't BUG_ON() in my tree. Does it correspond to mm.c:232 in
xen-ia64-unstable.hg of c/s 15162:0cf6b75423e9?
If so, the pte entry is already updated to point to mfn so that
old_mfn shouldn't be involved.

Could you elaborate on details?
- paravirtualized domain or domVTi?
- What is the activity to trigger assign_domain_page_replace() with
  pte_mem(old_pte) true?

thanks,
-- 
yamahata

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