Re: Add the hook kvm_arch_set_memory region to hold mmu-specific changes

[Carsten Otte <cotte-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>]

Zhang, Xiantao wrote:
> Patch [3/3] Add the hook kvm_arch_set_memory_region.  In this patch,
> introduce a function kvm_caculate_mmu_pages to compute mmu pages in
> total, once memory region changes.diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c

index bda733a..a4a32bd 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -332,29 +332,9 @@ int __kvm_set_memory_region(struct kvm *kvm,
  	if (mem->slot >= kvm->nmemslots)
  		kvm->nmemslots = mem->slot + 1;

-	if (!kvm->n_requested_mmu_pages) {
-		unsigned int n_pages;
-
-		if (npages) {
-			n_pages = npages * KVM_PERMILLE_MMU_PAGES / 1000;
-			kvm_mmu_change_mmu_pages(kvm, kvm->n_alloc_mmu_pages +
-						 n_pages);
-		} else {
-			unsigned int nr_mmu_pages;
-
-			n_pages = old.npages * KVM_PERMILLE_MMU_PAGES / 1000;
-			nr_mmu_pages = kvm->n_alloc_mmu_pages - n_pages;
-			nr_mmu_pages = max(nr_mmu_pages,
-				        (unsigned int) KVM_MIN_ALLOC_MMU_PAGES);
-			kvm_mmu_change_mmu_pages(kvm, nr_mmu_pages);
-		}
-	}

  	*memslot = new;

-	kvm_mmu_slot_remove_write_access(kvm, mem->slot);
-	kvm_flush_remote_tlbs(kvm);
-
  	kvm_free_physmem_slot(&old, &new);
  	return 0;

@@ -374,6 +354,8 @@ int kvm_set_memory_region(struct kvm *kvm,

  	mutex_lock(&kvm->lock);
  	r = __kvm_set_memory_region(kvm, mem, user_alloc);
+	if (r == 0)
+		kvm_arch_set_memory_region(kvm, mem);
  	mutex_unlock(&kvm->lock);
  	return r;
  }
This split of __kvm_set_memory_region assumes that all architectures 
have physmem slots. I support Avi's suggestion to have user allocated 
memory as new portable approach, and this old kernel-allocation based 
one x86 only. If that's where we're heading, this split is the wrong 
approach. I think we can come up with something smarter then "move the 
whole thing to x86" in this case, but all cases that have user_alloc 
== 1 should really be handled by x86.c code.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/