On Monday 28 June 2010 14:56:38 Avi Kivity wrote: > On 06/28/2010 09:42 AM, Sheng Yang wrote: > >>> +static void wbinvd_ipi(void *garbage) > >>> +{ > >>> + wbinvd(); > >>> +} > >> > >> Like Jan mentioned, this is quite heavy. What about a clflush() loop > >> instead? That may take more time, but at least it's preemptible. Of > >> course, it isn't preemptible in an IPI. > > > > I think this kind of behavior happened rarely, and most recent processor > > should have WBINVD exit which means it's an IPI... So I think it's maybe > > acceptable here. > > Several milliseconds of non-responsiveness may not be acceptable for > some applications. So I think queue_work_on() and a clflush loop is > better than an IPI and wbinvd. OK... Would update it in the next version. -- regards Yang, Sheng > > >>> + > >>> > >>> void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu) > >>> { > >>> > >>> + /* Address WBINVD may be executed by guest */ > >>> + if (vcpu->kvm->arch.iommu_domain) { > >>> + if (kvm_x86_ops->has_wbinvd_exit()) > >>> + cpu_set(cpu, vcpu->arch.wbinvd_dirty_mask); > >>> + else if (vcpu->cpu != -1) > >>> + smp_call_function_single(vcpu->cpu, > >>> + wbinvd_ipi, NULL, 1); > >> > >> Is there any point to doing this if !has_wbinvd_exit()? The vcpu might > >> not have migrated in time, so the cache is flushed too late. > > > > For the !has_wbinvd_exit(), the instruction would be executed by guest > > and flush the current processor immediately. And we can ensure that it's > > clean in the last CPU, so we're fine. > > Ah, yes. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html