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

Reply via email to