(2012/01/24 23:35), Takuya Yoshikawa wrote:
On Tue, 24 Jan 2012 13:24:56 +0200
Avi Kivity<avi@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
