Re: [PATCH 4/4 v3] KVM: Introduce kvm_memory_slot::arch and move lpage_info into it

[Alexander Graf <agraf@suse.de>]

On 03/07/2012 05:46 AM, Takuya Yoshikawa wrote:
> Alexander Graf<agraf@suse.de>  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