On Wed, Sep 18, 2024, Lilit Janpoladyan wrote:
> +static int kvm_commit_memory_region(struct kvm *kvm,
> + struct kvm_memory_slot *old,
> + const struct kvm_memory_slot *new,
> + enum kvm_mr_change change)
> {
> + int r;
> int old_flags = old ? old->flags : 0;
> int new_flags = new ? new->flags : 0;
> /*
> @@ -1709,6 +1710,10 @@ static void kvm_commit_memory_region(struct kvm *kvm,
> int change = (new_flags & KVM_MEM_LOG_DIRTY_PAGES) ? 1 : -1;
> atomic_set(&kvm->nr_memslots_dirty_logging,
> atomic_read(&kvm->nr_memslots_dirty_logging) + change);
> + if (change > 0)
> + r = kvm_arch_enable_dirty_logging(kvm, new);
> + else
> + r = kvm_arch_disable_dirty_logging(kvm, new);
There's zero reason to add new arch callbacks, the entire reason
kvm_arch_commit_memory_region() exists is to let arch code react to memslot
changes. As evidenced by the fact that multiple architectures already handle
dirty logging changes in their commit hooks, it's trivial to detect changes, i.e.
not worth moving to generic code.
