On 02/16/2012 06:50 AM, Xiao Guangrong wrote:
> I think we do not need handle all tlb-flushed request here since all of these
> request can be delayed to the point where mmu-lock is released , we can simply
> do it:
>
> void kvm_mmu_defer_remote_flush(kvm, need_flush)
> {
> if (need_flush)
> ++kvm->tlbs_dirty;
> }
>
> void kvm_mmu_commit_remote_flush(struct kvm *kvm)
> {
> int dirty_count = kvm->tlbs_dirty;
>
> smp_mb();
>
> if (!dirty_count)
> return;
>
> if (make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH))
> ++kvm->stat.remote_tlb_flush;
<-- point A
> cmpxchg(&kvm->tlbs_dirty, dirty_count, 0);
> }
>
> if this is ok, we only need do small change in the current code, since
> kvm_mmu_commit_remote_flush is very similar with kvm_flush_remote_tlbs().
Suppose at point A another thread executes defer_remote_flush(),
commit_remote_flush(), and defer_remote_flush() again. This brings the
balue of tlbs_dirty back to 1 again, with the tlbs dirty. The cmpxchg()
then resets tlbs_dirty, leaving the actual tlbs dirty.
--
error compiling committee.c: too many arguments to function
--
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
