Carsten Otte wrote: > 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 >
> 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. User-allocation should be what we are heading. But considering compatibility with old user-space support, I think kernel-allocation approach should exist for a long time. I think we don't need to consider this case now. Once the kernel-allocation approach is abandoned in future, as you say, we can move them all into x86. Xiantao ------------------------------------------------------------------------- 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel