Message ID | 552C91BA.1010703@linux.intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
> - * Only EPT supported for now; otherwise, one would need to > - * find out efficiently whether the guest page tables are > - * also using huge pages. > + * We can not do huge page mapping for the indirect shadow > + * page (sp) found on the last rmap (level = 1 ) since > + * indirect sp is synced with the page table in guest and > + * indirect sp->level = 1 means the guest page table is > + * using 4K page size mapping. What about: + * We cannot do huge page mapping for indirect shadow pages, + * which are found on the last rmap (level = 1) when not using + * tdp; such shadow pages are synced with the page table in + * the guest, and the guest page table is using 4K page size + * mapping if the indirect sp has level = 1. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/15/2015 11:05 PM, Paolo Bonzini wrote: > > >> - * Only EPT supported for now; otherwise, one would need to >> - * find out efficiently whether the guest page tables are >> - * also using huge pages. >> + * We can not do huge page mapping for the indirect shadow >> + * page (sp) found on the last rmap (level = 1 ) since >> + * indirect sp is synced with the page table in guest and >> + * indirect sp->level = 1 means the guest page table is >> + * using 4K page size mapping. > > What about: > > + * We cannot do huge page mapping for indirect shadow pages, > + * which are found on the last rmap (level = 1) when not using > + * tdp; such shadow pages are synced with the page table in > + * the guest, and the guest page table is using 4K page size > + * mapping if the indirect sp has level = 1. Yeah, much better. Thanks for your improvement, Paolo! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 15, 2015 at 05:05:48PM +0200, Paolo Bonzini wrote: > > >> - * Only EPT supported for now; otherwise, one would need to >> - * find out efficiently whether the guest page tables are >> - * also using huge pages. >> + * We can not do huge page mapping for the indirect shadow >> + * page (sp) found on the last rmap (level = 1 ) since >> + * indirect sp is synced with the page table in guest and >> + * indirect sp->level = 1 means the guest page table is >> + * using 4K page size mapping. > >What about: > >+ * We cannot do huge page mapping for indirect shadow pages, >+ * which are found on the last rmap (level = 1) when not using >+ * tdp; such shadow pages are synced with the page table in >+ * the guest, and the guest page table is using 4K page size >+ * mapping if the indirect sp has level = 1. Reviewed-by: Wanpeng Li <wanpeng.li@linux.intel.com> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 146f295..68c5487 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -4481,9 +4481,11 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm, pfn = spte_to_pfn(*sptep); /* - * Only EPT supported for now; otherwise, one would need to - * find out efficiently whether the guest page tables are - * also using huge pages. + * We can not do huge page mapping for the indirect shadow + * page (sp) found on the last rmap (level = 1 ) since + * indirect sp is synced with the page table in guest and + * indirect sp->level = 1 means the guest page table is + * using 4K page size mapping. */ if (sp->role.direct && !kvm_is_reserved_pfn(pfn) &&
Soft mmu uses direct shadow page to fill guest large mapping with small pages if huge mamping is disallowed on host. So zapping direct shadow page works well both for soft mmu and hard mmu Fix the comment to reflect this truth Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com> --- arch/x86/kvm/mmu.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)