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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] Re: [PATCH]: ptc.ga for SMP-g
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Thu, 30 Mar 2006 10:25:18 +0100
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 30 Mar 2006 09:22:58 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD8094E7A38@pdsmsx403>
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: <571ACEFD467F7749BC50E0A98C17CDD8094E7A38@pdsmsx403>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Jeudi 30 Mars 2006 11:08, Tian, Kevin a écrit :
> 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.
Correct.  There is indeed a race between purge and insert.

> 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?
For sure, this is almost the safest.  But there is still a race-condition: if 
vcpu migrates during the IPI, the tlb can be modified by two cpus.

> >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...
This is not an SMP-g issue, but an SMP issue.
After migration to CPU Y, the VHPT for CPU X is not updated.  When it migrates 
again to CPU X, it has an oudated VHPT.

So, in short migration is *not* handled.

Tristan.



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