From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: KVM EPT implementation Date: Fri, 29 Mar 2013 10:20:28 +0100 Message-ID: <51555CDC.6070605@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Tony Roberts Return-path: Received: from mail-qc0-f176.google.com ([209.85.216.176]:47205 "EHLO mail-qc0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754957Ab3C2JUf (ORCPT ); Fri, 29 Mar 2013 05:20:35 -0400 Received: by mail-qc0-f176.google.com with SMTP id n41so159593qco.35 for ; Fri, 29 Mar 2013 02:20:34 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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