[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel] RFC: ptc.ga implementation for SMP-g


  • To: "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
  • Date: Tue, 4 Apr 2006 22:47:00 +0800
  • Delivery-date: Tue, 04 Apr 2006 07:47:26 -0700
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcZX8cwCJ5MZfoyLRFW8wv4v/6Cw+gAApt7A
  • Thread-topic: [Xen-ia64-devel] RFC: ptc.ga implementation for SMP-g

>From: Tristan Gingold 
>dtlb and itlb are cleared unconditionnaly.
>However you are right, the VHPT entry is not the good one.  I think this is a
>good reason not to do it with the IPI, but to clear directly the entry.
>
Yes, resetting the rid impacts the performance, that makes IPI method worse.
I have an idea about handling ptc.ga. But I am not sure whether it is feasible.

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.

There is a time window between purges of vcpu1 and vcpu2, I'm not sure 
whether it is workable.

Thanks,
Anthony

>Tristan.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.