Re: [PATCH 10/18] KVM: Move x86's MMU notifier memslot walkers to generic code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 31/03/21 18:20, Sean Christopherson wrote:
Every call
to .change_pte() is bookended by .invalidate_range_{start,end}(), i.e. the above
missing kvm->mmu_notifier_seq++ is benign because kvm->mmu_notifier_count is
guaranteed to be non-zero.

In fact ARM even relies on invalidate wrapping the change_pte handler.

        /*
         * The MMU notifiers will have unmapped a huge PMD before calling
         * ->change_pte() (which in turn calls kvm_set_spte_hva()) and
         * therefore we never need to clear out a huge PMD through this
         * calling path and a memcache is not required.
         */

Assuming all of the above is correct, I'm very tempted to rip out .change_pte()
entirely.

There is still the performance benefit from immediately remapping the page to the new destination without waiting for a fault. Yes it's hypothetical but I would prefer to leave that change for later.

The fact that the count is nonzero means that you will not even have to complicate kvm_mmu_notifier_change_pte to handle the removal of mmu_notifier_seq; just add a patch before this one to WARN if it is zero. (The rest of my review to patch 16 still holds).

Paolo

It's been dead weight for 8+ years and no one has complained about
KSM+KVM performance (I'd also be curious to know how much performance was gained
by shaving VM-Exits).  As KVM is the only user of .change_pte(), dropping it in
KVM would mean the entire MMU notifier could also go away.


_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm



[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux