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] RFC: ptc.ga implementation for SMP-g

To: "Xu, Anthony" <anthony.xu@xxxxxxxxx>, "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] RFC: ptc.ga implementation for SMP-g
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Tue, 4 Apr 2006 12:46:13 -0700
Delivery-date: Tue, 04 Apr 2006 12:47:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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: AcZX+1SsKcDEeYmsQJCiYi6jVISCOAAAdEwwAAighpA=
Thread-topic: [Xen-ia64-devel] RFC: ptc.ga implementation for SMP-g
> >> >> The control flow is as below
> >> >> 1. vcpu1 emulates ptc.ga
> >> >> 2. vcpu1 executes vhpt_flush_address to purge current LP VHPT,
> >> >>   and executes ptc.l to purge machine TLB on current LPs.
> >> >> 3. vcpu1 creates a structure which describe this 
> ptc.ga, including
> >> >> virtual address, address range and rid, and connect 
> this structure to
> >> >> vcpu2. 4. then vcpu1 sets a flag in vcpu2, indicating 
> there is ptc.ga
> >> >> executed on this VMM.
> >> >> 5. When vcpu2 traps into hypervisor, hypervisor will 
> check whether this
> >> >>   flag is set, if yes, vcpu2 will execute 
> vhpt_flush_address and ptc.l.
> >> >
> >> >  6. vcpu1 waits for vcpu2 until it has done the job.
> >> >
> >> >> There is a time window between purges of vcpu1 and 
> vcpu2, I'm not sure
> >> >> whether it is workable.
> >> >
> >> >The IPI could makes vcpu2 entering into the hypervisor faster.
> >>
> >> Yes, but IPI will cause extra save/restore on other vcpus.
> >Right.
> >> And as you said IPI may cause trouble when considering migration.
> >> If above method is feasible, I prefer this one.
> >How to be sure the time window is not too long ?
> >vcpu1 must waits for vcpu2.
> Sorry for not clear, IMO vcpu1 doesn't need to wait vcpu2.
> Vcpu1 also doesn't wait vcpu2 by using IPI, is here any issue?

I think ptc.ga needs to execute as a "transaction", that is,
it is not complete until all other processors' translations
have been purged.  If not, consider (in the above):

4.5. vcpu2 doesn't trap to the hypervisor for a very long time
     and continues to use the unpurged translation, while vcpu1
     assumes the translation has been successfully purged and
     sets up a new translation and assumes that vcpu2 will "miss"
     and use the new translation.

Dan

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