On 03/07/2012 05:46 AM, Takuya Yoshikawa wrote:
Alexander Graf<agraf@xxxxxxx> wrote:
This patch is the first step to make this difference clear by
introducing kvm_memory_slot::arch; lpage_info is moved into it.
I am planning to move rmap stuff into arch next if this patch is accepted.
Please let me know if you have some opinion about which members should be
moved into this.
What is this lpage stuff? When do we need it? Right now the code gets executed on ppc, right? And with the patch it doesn't, no?
lpage_info is used for supporting huge pages on kvm-x86: we have
write_count and rmap_pde for each largepage and these are in lpage_info.
At the time I made this patch, it seemed that only kvm-x86 supported
huge pages, on ppc the array should be empty:
Hrm. I suppose this refers to transparent huge pages? Andrea, Paul, is
there anything keeping is from also needing/using that logic?
/* We don't currently support large pages. */
#define KVM_HPAGE_GFN_SHIFT(x) 0
#define KVM_NR_PAGE_SIZES 1
How each architecture supports huge pages will differ a lot.
So this kind of memory consuming stuff should be arch specific.
Yeah, probably.
IMO rmap also should to be moved into the arch.
s390 does not need it and other architectures than x86 will be happy if
the type of it can be changed from unsigned long to a pointer, no?
How would an unsigned long make a difference over a pointer?
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
