RE: [Xen-ia64-devel] Re: [PATCH]: ptc.ga for SMP-g

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx]
>Sent: 2006年3月30日 16:56
>
>> >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.
>This is as if the purge was done a few cycles after the checks.

OK, maybe we can take another extreme case. :-) Say current vcpu 
doesn't check the vtlb entry, instead it tries to update that entry and more 
interesting is that it wants to set present bit. Now if another vcpu clears 
present bit of this entry before current vcpu's update, finally that entry will 
be in present state again. That's one race condition. The importance is 
that one vcpu doesn't know whether another vcpu is operating that 
context. However with IPI's help, all modifications happen on current 
context. To avoid race with interrupted context, IPI handler may even raise 
a softirq to handle purge only before resuming to guest. How do you 
think?

>
>The main problem with IPI is migration.  However, currently migration
>doesn't
>work well.  I think it is ok to migrate a vcpu from CPU X to CPU Y, but
>we
>don't support migrating back from CPU Y to CPU X.

Elaboration? Curious about the reason...

Thanks,
Kevin

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