Re: EPT page fault procedure

[Paolo Bonzini <pbonzini@redhat.com>]

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