[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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Tue, 4 Apr 2006 17:15:19 +0800
  • Delivery-date: Tue, 04 Apr 2006 02:15:37 -0700
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcZXxY+hcGi0zCflSUK3RIn6L0tCwAAABNaw
  • Thread-topic: [Xen-ia64-devel] RFC: ptc.ga implementation for SMP-g

>From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx]
>Sent: 2006年4月4日 17:00
>As Isaku pointed out, vcpu_translate is run with psr.i = 1.  (I think this is
>true).
>Therefore an IPI doesn't avoid the race.

That's not the necessary case. If current running vcpu is not the target 
one, you can operate the vtlb of target vcpu directly in IPI handler. Or else, 
IPI handler can simply set a flag to target vcpu and then purge the vtlb at 
resuming to guest. 

>
>BTW, I'd prefer to completly avoid IPI for ptc.ga.  From a few tests, IPI
>are
>too slow to implement ptc.ga.
>

I agree, and hope to see your solutions. But just be careful to not 
introduce overhead to other parts when improving ptc.ga emulation.
Another suggestion would be, please consider the hash tlb approach from 
now on, when you make design choices. :-)

Thanks,
Kevin

_______________________________________________
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®.