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: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] Modify to introduce delayed p2m table destruction
From: Doi.Tsunehisa@xxxxxxxxxxxxxx
Date: Mon, 06 Nov 2006 09:37:32 +0900
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 05 Nov 2006 16:37:59 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: Your message of Thu, 02 Nov 2006 21:58:32 +0900. <20061102125832.GA31845%yamahata@xxxxxxxxxxxxx>
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> <200611021055.kA2AtrF07257@xxxxxxxxxxxxxxxxxxxxxxxxxxx><20061102125832.GA31845%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi,

You (yamahata) said:
>>> - Probably IA64 specific code paths assume that if the p2m conversion
>>>   gives valid mfn, then the page isn't free.
>>>   Your patch breaks it. I haven't check it though.
>> 
>>   In our investigation, the domain is paused at domain_kill phase, thus
>> it don't occur the issue, and x86 code had introduced same logic.
> 
> Although all vcpus of the domain are paused,
> how about another domain's vcpu?
> It might be possible for another domain's vcpu to modify
> the p2m table.

  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'.

  In other hand, p2m table of other domain might become to refer the
same page frame which has used by destructing domain. In this case,
get_page() is final guard to avoid memory coruption. In x86 code, it
is introduced same logic. I discussed about the delayed p2m table
destruction in xen-devel community, thus I confirmed it. I suppose
that it avoids to be too heavy to comform.

> And one more comment.
> - your patch breaks page reference convension.

  During domain creation and destruction, it might be broken, but
it has to do, I think.

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

Thanks,
- Tsunehisa Doi

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