Re: KVM EPT implementation

[Paolo Bonzini <pbonzini@redhat.com>]

Il 28/03/2013 17:06, Tony Roberts ha scritto:
> 
> I was hoping somebody might be able to point me to the correct
> location within the KVM source code to track when EPT entries are
> actually written to the various tables in the 4 level hierarchy.  The
> function pte_list_add seems to do nothing more than change the value
> of a pointer, but only the first address passed to it is page aligned
> (the PML4 base) and the rest of the addresses appear to be pointers
> into existing pages, often seeming to be outside of the PML4 page
> range.

The EPT tables are built lazily, as if they were shadow page tables.
There is "only" one difference in how they're built; namely, the tables
do not include the gva->gpa (guest virtual address->guest physical
address) translation.

This is very similar to how KVM builds shadow page tables when the guest
is running without pages.  In both cases we have to build a page table
for gpa->hpa translation ("standard" OS page tables are hva->hpa).  In
fact, many callbacks are shared between the two cases, and even when
they're not there are similarities.  You can see that both
nonpaging_page_fault and tdp_page_fault invoke __direct_map, for example.

What makes the difference, of course, is that EPT tables are hardly ever
invalidated:

1) nonpaging_invlpg and nonpaging_sync_page are no-ops; this is also the
case with shadow page tables in nonpaging mode, as the names suggest.

2) neither invlpg nor CR3 loads and stores cause a vmexit in EPT mode.
kvm_set_cr3, and hence (via nonpaging_new_cr3) mmu_free_roots, are
hardly ever called.  You could get a call from the emulator in rare
cases, which would cause a spurious flush, but that never happens in
practice.

(This doesn't include nested virtualization, which uses the MMU in
another mode with its own callbacks---see init_kvm_nested_mmu.  I think
this is beyond what you currently care about, though).

Paolo