On Tue, Aug 7, 2012 at 10:54 AM, Avi Kivity <avi@xxxxxxxxxx> wrote: > On 08/07/2012 05:42 PM, Marc Zyngier wrote: >> On 07/08/12 15:23, Avi Kivity wrote: >>> On 08/07/2012 05:15 PM, Marc Zyngier wrote: >>> >>>>> vcpu migration is supposed to be transparent. What happens if you >>>>> perform the operation locally, then the vcpu is migrated? >>>> >>>> Migrated as in "moved to another physical CPU"? We have a per-vcpu cpumask >>>> indicating which CPU must perform a full cache clean/invalidate, which we >>>> test in kvm_arch_vcpu_load(). >>>> >>> >>> How is the cpumask maintained? All cpus which were touched by the vcpu? >> >> Each time we trap a cache invalidate by set/way (and only these), we >> perform it on the the local CPU, and flag all other CPUs to nuke their >> own caches if they ever run this vcpu (using the above cpumask). >> >> Whenever this vcpu is schedule on another CPU, we execute this from >> kvm_arch_vcpu_load(): >> /* >> * Check whether this vcpu requires the cache to be flushed on >> * this physical CPU. This is a consequence of doing dcache >> * operations by set/way on this vcpu. We do it here to be in >> * a non-preemptible section. >> */ >> if (cpumask_test_and_clear_cpu(cpu, &vcpu->arch.require_dcache_flush)) >> flush_cache_all(); /* We'd really want v7_flush_dcache_all() */ >> > > I see. Then you don't need the entire exit path to be non-preemptible. > You could, in the invalidate handler, do: > > preempt_disable() > cpumask_setall() > cpumask_clear(me) > perform local operation > preempt_enable() > > Whether we're migrated before or after, we should be safe. see git repo: https://github.com/virtualopensystems/linux-kvm-arm/commit/d611960b0745d759e26e77ca47ef3274237e4b65 or list archive: https://lists.cs.columbia.edu/pipermail/kvmarm/2012-July/002695.html > > btw, seems there is a needless atomic operation above. May be > worthwhile to test before clearing. > > you mean in vcpu_load you want to do this instead: if (cpumask_test_cpu(cpu, &vcpu->arch.require_dcache_flush)) >> >>> btw, x86 mostly ignores cache invalidates (an exception is device >>> assignment). >> >> We cannot afford this on ARM when executing an invalidate by set/way. >> All the other cache maintenance operations are safe and run on the guest. > > I see now, thanks for the explanations. > > > -- > error compiling committee.c: too many arguments to function _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
