Re: [kvm-devel] Add the hook kvm_arch_set_memory region to hold mmu-specific changes
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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Add the hook kvm_arch_set_memory region to hold mmu-specific changes
Zhang, Xiantao wrote: 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. That's right. This is why I would prefer to have the corresponding code out of kvm_main.c: it may exist for a long time for x86. 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. I'd rather prefer to move it upfront. Otherwise, I'd have to consider that case for s390 as long as it remains in common. At least I'd have to make sure it does'nt get used on s390 using an if() or #ifdef. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Add the hook kvm_arch_set_memory region to hold mmu-specific changes
Carsten Otte wrote: Zhang, Xiantao wrote: 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. That's right. This is why I would prefer to have the corresponding code out of kvm_main.c: it may exist for a long time for x86. 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. I'd rather prefer to move it upfront. Otherwise, I'd have to consider that case for s390 as long as it remains in common. At least I'd have to make sure it does'nt get used on s390 using an if() or #ifdef. I agree, other archs shouldn't have to suffer. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Add the hook kvm_arch_set_memory region to hold mmu-specific changes
Avi Kivity wrote: Carsten Otte wrote: Zhang, Xiantao wrote: 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. That's right. This is why I would prefer to have the corresponding code out of kvm_main.c: it may exist for a long time for x86. 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. I'd rather prefer to move it upfront. Otherwise, I'd have to consider that case for s390 as long as it remains in common. At least I'd have to make sure it does'nt get used on s390 using an if() or #ifdef. I agree, other archs shouldn't have to suffer. So, now we move the whole thing(__kvm_set_memory_region) into arch ? :) Xiantao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
