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] Re: [PATCH]: ptc.ga for SMP-g

To: "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Re: [PATCH]: ptc.ga for SMP-g
From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Date: Thu, 30 Mar 2006 16:59:35 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 30 Mar 2006 09:01:35 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZT089RSmVdy9gVQuiE7GXAhevH7QAAu0Gw
Thread-topic: [Xen-ia64-devel] Re: [PATCH]: ptc.ga for SMP-g
>From: Tristan Gingold
>Sent: 2006?3?30? 16:31
>To: Isaku Yamahata
>Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-ia64-devel] Re: [PATCH]: ptc.ga for SMP-g
>
>Le Mardi 28 Mars 2006 04:04, Isaku Yamahata a écrit :
>> Hi Tristan.
>>
>>
>> +                    /* Purge tc entry.
>> +                       Can we do this directly ?  Well, this is just a
>> +                       single atomic write.  */
>> +                    vcpu_purge_tr_entry(&PSCBX(v,dtlb));
>> +                    vcpu_purge_tr_entry(&PSCBX(v,itlb));
>>
>> These aren't SMP-safe because dtlb isn't read atomically.
>> From vcpu_translate()
>>
>> #define vcpu_match_tr_entry(_trp,_ifa,_rid)             \
>>     ((_trp->p && (_trp->rid==_rid) && (_ifa >= _trp->vadr) &&   \
>>     (_ifa < (_trp->vadr + (1L<< _trp->ps)) - 1)))
>>
>>         trp = &vcpu->arch.dtlb;
>>         if (/* is_data && */ vcpu_match_tr_entry(trp,address,rid)) {
>>                 <<<<<<<<<<<<If other processor executes
>>                             vcpu_purge_tr_entry(&PSCBX(v,dtlb)) here,
>>                             then a disaster will happen >>>>>>>>>>>>>>>>
>Can you elaborate ? Do you have a disaster scenario ?
>vcpu_purge_tr_entry only clears the p bit.
>
>> In fact it's more subtle because of memory ordering.
>I don't think it is the case, because vcpu_purge_tr_entry modify only one bit
>in one word.

There seems no issue, because vcpu_purge_tr_entry() only sets ->p=0.
In some cases, this patch may cause a not-present tlb inserted into machine 
TLB, this is harmless, when guest accesses this page, page not present fault
 happens, and guest kernel will purge this tlb and insert a new one, there are 
a little performance penalty.
Sine you will send IPI to flush vhpt later, why not purge this tlb as well as 
flush vhpt.


Thanks,
Anthony

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