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] Modify to introduce delayed p2m table destruction

To: Doi.Tsunehisa@xxxxxxxxxxxxxx
Subject: Re: [Xen-ia64-devel] Modify to introduce delayed p2m table destruction
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Mon, 6 Nov 2006 10:33:38 +0900
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 05 Nov 2006 17:33:54 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200611060037.kA60bWF16952@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <20061102103405.GA17534%yamahata@xxxxxxxxxxxxx> <200611060037.kA60bWF16952@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Mon, Nov 06, 2006 at 09:37:32AM +0900, Doi.Tsunehisa@xxxxxxxxxxxxxx wrote:
>   I think, the p2m table of the domain (during destruction indeed)
> is not modified by any domain. Gran table reference has a possiblity
> of p2m table modified by other domain, but in this case, grant table
> reference releases before `shadow_teardown'.

Grant table page transfer does. (So In fact before this issue raise,
the p2m destruction code was already broken. Fortunately
no one hit this.)


> > - your patch breaks page reference convension.
>   During domain creation and destruction, it might be broken, but
> it has to do, I think.

What do you mean by "destruction"?
It's so sutble that you had to defer the p2m table freeing, didn't you?
After arch_domain_destroy() no other domain modify the p2m table,
so breaking the page reference convesion is O.K. after that.
However during shadow_teardown_xxx() in your patch
other domain might access the p2m table and struct page_info.
Page reference convension must be kept right during them.


> >>> - Why shadow prefix? it isn't related to shadow.
> >> 
> >>   In IA64 code, it doesn't have shadow page table, but it regards
> >> that it has shadow mode, I think. Thus I adopted shadow prefix to
> >> follow other arch.
> > 
> > Shadow prefix is confusing here. (At least for me)
> 
>   I don't have so good idea. 
> 
>   What do you think about below ?
> 
>     - shadow_teardown        ->  teardown_mm
>     - shadow_final_teardown  ->  final_teardown_mm
>     - shadow_p2m_teardown    ->  final_p2m_teardown

How about s/shadow/mm/ ?


-- 
yamahata

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