Re: Calling to kvm_mmu_load

[Paolo Bonzini <pbonzini@redhat.com>]

Il 24/10/2013 08:55, Arthur Chunqi Li ha scritto:
> Hi Paolo,
> 
> Thanks for your reply.
> 
> On Wed, Oct 23, 2013 at 2:21 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 21/10/2013 08:56, Arthur Chunqi Li ha scritto:
>>> Hi there,
>>>
>>> I noticed that kvm_mmu_reload() is called every time in vcpu enter,
>>> and kvm_mmu_load() is called in this function when root_hpa is
>>> INVALID_PAGE. I get confused why and when root_hpa can be set to
>>> INVALID_PAGE? I find one condition that if vcpu get request
>>> KVM_REQ_MMU_RELOAD, kvm_mmu_unload() is called to invalid root_hpa,
>>> but this condition cannot cover all occasions.
>>
>> Look also at mmu_free_roots, kvm_mmu_unload and kvm_mmu_reset_context.
>> In "normal" cases and without EPT, it should be called when CR3 changes
>> or when the paging mode changes (32-bit, PAE, 64-bit, no paging).  With
>> EPT, this kind of change won't reset the MMU (CR3 changes won't cause a
>> vmexit at all, in fact).
> 
> When EPT is enabled, why will root_hpa be set to INVALID_PAGE when a
> VM boots?

Because EPT page tables are only built lazily.  The EPT page tables
start all-invalid, and are built as the guest accesses pages at new
guest physical addresses (instead, shadow page tables are built as the
guest accesses pages at new guest virtual addresses).

> I find that Qemu reset root_hpa with KVM_REQ_MMU_RELOAD
> request several time when booting a VM, why?

This happens when the memory map changes.  A previously-valid guest
physical address might become invalid now, and the EPT page tables have
to be "emptied".

> And will VM use EPT from the very beginning when booting?

Yes.  But it's not the VM.  It's KVM that uses EPT.

The VM only uses EPT if you're using nested virtualization, and EPT is
enabled.  L1's KVM uses EPT, L2 doesn't (because it doesn't run KVM).

>> With nested virtualization, roots are invalidated whenever kvm->arch.mmu
>> changes meaning from L1->L0 or L2->L0 or vice versa (in the special case
>> where EPT is disabled on L0, this is trivially because vmentry loads CR3
>> from the vmcs02).
> 
> Besides, in function tdp_page_fault(), I find two different execution
> flow which may not reach __direct_map() (which I think is the normal
> path to handle PF), they are fast_page_fault() and try_async_pf().
> When will these two paths called when handling EPT page fault?

fast_page_fault() is called if you're using dirty page tracking.  It
checks if we have a read-only page that is in a writeable memory slot
(SPTE_HOST_WRITEABLE) and whose PTE allows writes (SPTE_MMU_WRITEABLE).
 If these conditions are satisfied, the page was read-only because of
dirty page tracking; it is made read-write with a single cmpxchg and
sets the bit for the page in the dirty bitmap.

try_async_pf will inject a "dummy" pagefault instead of creating the EPT
page table, and create the page table in the background.  The guest will
do something else (run another task) until the EPT page table has been
created; then a second "dummy" pagefault is injected.
kvm_arch_async_page_not_present signals the first page fault,
kvm_arch_async_page_present signals the second.  For this to happen, the
guest must have enabled the asynchronous page fault feature with a write
to a KVM-specific MSR.

Paolo