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: Tue, 07 Nov 2006 12:36:35 +0900
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 06 Nov 2006 19:37:01 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: Your message of Tue, 07 Nov 2006 11:01:57 +0900. <20061107020157.GD2868%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> <200611060615.kA66FMF21162@xxxxxxxxxxxxxxxxxxxxxxxxxxx><20061107020157.GD2868%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
  Thank you for your suggestion.

  We'll study it.

Thanks,
- Tsunehisa Doi


You (yamahata) said:
>>>>> 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.
>>>> 
>>>>   Yes, it might access them. In past, I thought so, but after
>>>> discussion about delayed p2m table destruction of shadow2, I've be
>>>> satisfied that get_page avoids memory corruption finally.
>>> 
>>> You might understand x86 shadow code.
>>> However you must understand IA64 code too.
>>> It would be effective to understand IA64 code by analogy of
>>> x86 shadow code, But they're different.
>> 
>>   Hmm, I don't understand the difference.
>> 
>>   Can you give me suggestion about the difference ?
> 
> The Xen/IA64 p2m table is lockless while Xen/x86 shadow p2m table 
> is protected by shadow_lock()/shadow_unlock().
> This is a burden to the Xen/IA64 p2m maintenance.
> So we must be very carefull when modifying it. 
> Especially we must be aware of memory ordering.
> This is the reason why volatile is sprinckled.
> 
> In Xen/IA64 p2m case
> page reference count must be increased before you add the new entry,
> page reference count must be decreased after removing the entry.
> The only exception is relinquish_pte() because it assumes that 
> the p2m itself is freed. (But this assumption is wrong.)
> However Xen/x86 shadow p2m doesn't care abount page reference count.
> 
> The blktap patches which I sent out last night impose a one more new rule
> which is related to PGC_allocated flag.
> The patch introduces _PAGE_PGC_ALLOCATED.
> When the p2m entry is removed and _PAGE_PGC_ALLOCATED bit is set,
> something like
> if (pte_pgc_allocated(old_pte)) {
>     if (test_and_clear(_PGC_allocated, &page->count_info))
>       put_page(page)
> }
> must be done. domain_put_page() takes care of it.
> 
> Thanks.
> -- 
> yamahata
> 

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

<Prev in Thread] Current Thread [Next in Thread>