[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |