From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takuya Yoshikawa Subject: Re: [PATCH 0/4] KVM: Decouple rmap_pde from lpage_info write_count Date: Wed, 25 Jan 2012 15:20:15 +0900 Message-ID: <4F1F9F1F.1030601@oss.ntt.co.jp> References: <20120123194204.268410c4.yoshikawa.takuya@oss.ntt.co.jp> <4F1E9508.6010205@redhat.com> <20120124233549.17cf98a619b05724cfab78ad@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , mtosatti@redhat.com, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org To: Takuya Yoshikawa Return-path: In-Reply-To: <20120124233549.17cf98a619b05724cfab78ad@gmail.com> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org (2012/01/24 23:35), Takuya Yoshikawa wrote: > On Tue, 24 Jan 2012 13:24:56 +0200 > Avi Kivity wrote: > >> On 01/23/2012 12:42 PM, Takuya Yoshikawa wrote: >>> The last one is an RFC patch: >>> >>> I think it is better to refactor the rmap things, if needed, before >>> other architectures than x86 starts large pages support. >>> >> >> Not commenting about the meat of the patches (not sufficiently recovered >> yet), but other architectures may not want the write_count stuff at all, >> or even kvm_memory_slot::rmap. It may make sense to move those members >> into a new kvm_memory_slot::arch arch-specific substructure. > > It seems nice. > > We can also put double buffering related things into that arch structure! > I will look again and take the new approach. > ... and I found __kvm_set_memory_region() was a bit complicated to make my work harder than necessary, especially: 1. around "#ifndef CONFIG_S390" which allocates rmap, lpage_info, dirty_bitmap 2. kvm_free_physmem_slot(free, dont) stuff 1 will naturally disappear, eliminating the need of ugly #ifdef and "(void)level;" warning killer, by introducing kvm_memory_slot::arch and related allocation functions: kvm_arch_alloc/init_*() But one thing I hesitate to do is introducing architecture specific version of 2: kvm_arch_free_physmem_slot(free, dont) @free, @dont technique is already a bit tricky and distributing this kind of style to other files than kvm_main.c will make the logic harder to follow. Though it may be a pain, doesn't it make sense to clean up this stuff? Takuya