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 -- 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
