On 07.08.2012, at 15:32, Avi Kivity <avi@xxxxxxxxxx> wrote:
> On 08/07/2012 01:57 PM, Alexander Graf wrote:
>> Some archs need to ensure that their icache is flushed when mapping a new
>> page. Add a callback to the generic code for an arch to implement any cache
>> flush logic it may need.
>>
>> Signed-off-by: Alexander Graf <agraf@xxxxxxx>
>> ---
>> virt/kvm/kvm_main.c | 6 +++++-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index d42591d..4e0882d 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -1161,8 +1161,12 @@ static pfn_t hva_to_pfn(unsigned long addr, bool atomic, bool *async,
>> pfn = get_fault_pfn();
>> }
>> up_read(¤t->mm->mmap_sem);
>> - } else
>> + } else {
>> pfn = page_to_pfn(page[0]);
>> +#ifdef __KVM_HAVE_ARCH_MAP_PAGE
>> + kvm_arch_map_page(page[0]);
>> +#endif
>> + }
>>
>
> Please call it unconditionally, and have a stub inline ifndef
> __KVM_HAVE_ARCH_MAP_PAGE.
Sure, works fine with me.
>
> Is this the correct place? Who says the caller of hva_to_pfn() is going
> to map it?
I don't think anyone is. However, we need the struct page, and all the generic kvm mm code tries hard to hide it from its users. The alternative would be to expose all those details, and I'm not sure that's a good idea.
Essentially, we don't care if we're overly cautious. Clearing one page too much is way better than clearing one too few.
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
