Re: [PATCH 0/4] KVM: Decouple rmap_pde from lpage_info write_count

[Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>]

(2012/01/24 23:35), Takuya Yoshikawa wrote:
> On Tue, 24 Jan 2012 13:24:56 +0200
> Avi Kivity<avi@redhat.com>  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