From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: EPT page fault procedure Date: Mon, 04 Nov 2013 13:20:42 +0100 Message-ID: <5277911A.3000707@redhat.com> References: <527236DD.5000804@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" To: Arthur Chunqi Li Return-path: Received: from mx1.redhat.com ([209.132.183.28]:35059 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751322Ab3KDMUq (ORCPT ); Mon, 4 Nov 2013 07:20:46 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Il 04/11/2013 02:05, Arthur Chunqi Li ha scritto: >> > Do you mean HVA to PFN? If so, you can look at function hva_to_pfn. :) > I mean in this procedure, how is physical memory actually allocated? > When qemu firstly initialized the mapping of its userspace memory > region to VM, the physical memory corresponding to this region are not > actually allocated. So I think KVM should do this allocation > somewhere. >> > >>> >> table. What is the point in tdp_page_fault() handling such mapping >>> >> from PVA to PFA? >> > >> > The EPT page table entry is created in __direct_map using the pfn >> > returned by try_async_pf. try_async_pf itself gets the pfn from >> > gfn_to_pfn_async and gfn_to_pfn_prot. Both of them call __gfn_to_pfn >> > with different arguments. __gfn_to_pfn first goes from GFN to HVA using >> > the memslots (gfn_to_memslot and, in __gfn_to_pfn_memslot, >> > __gfn_to_hva_many), then it calls hva_to_pfn. >> > >> > Ultimately, hva_to_pfn_fast and hva_to_pfn_slow is where KVM calls >> > functions from the kernel's get_user_page family. > What will KVM do if get_user_page() returns a page not really exists > in physical memory? In non-atomic context, hva_to_pfn_slow will swap that page in before returning (or start the swap-in and return immediately if the guest supports asynchronous page faults). In atomic context, hva_to_pfn would fail, but that only happens in debugging code (arch/x86/kvm/mmu_audit.c). Paolo