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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 30 Mar 2006 16:42:54 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 30 Mar 2006 08:44:21 +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: AcZT09Uz4UI0Eo6+ROahwRjd28e5iQAAUXEw
Thread-topic: [Xen-ia64-devel] Re: [PATCH]: ptc.ga for SMP-g
>From: Tristan Gingold
>Sent: 2006年3月30日 16:31
>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.

I think it's not safe for one vcpu to operate date structure on another vcpu. 
For example, current vcpu is doing vcpu_match_tr_entry. Just after 
checking _trp->p, then another vcpu invokes vcpu_purge_tr_entry to clear 
_trp->p. In this case, vcpu_match_tr_entry should return false however it 
may return true based on old knowledge since the whole check is not 
atomic.

The preferred way is to only purge entry on its own context by sending IPI. 
For example, you can put vcpu_purge_tr_entry into ptc_ga_remote_func 
which will execute in right vcpu owning that entry.

Thanks,
Kevin

>
>> 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.
>
>
>Thank you for the comment.
>
>Tristan.
>
>
>
>_______________________________________________
>Xen-ia64-devel mailing list
>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-ia64-devel

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