Andrea Arcangeli wrote: > Oh I see! So when linux pte is cleared, the NPT equivalent is > implicitly and atomically cleared too. That really requires _identical_ > semantics and formats for both pagetables. Bingo. We have that on s390, and it seems workable on npt too.
> That problem is quite easily fixable by only sharing a 3rd level > pagetable hand having the NPT-pgd filled with only that shared 3rd > level linux pagetable. The guest ram can be allocated with MAP_FIXED > at a proper 512G aligned address. That has the cons to reduce the max > VM (_virtual_ adding more swap won't help) size to 512G. For the 64bit > kernel that may not be really a problem, for 32bit it's likely a > blocker instead. What worries me more are the details of the pte and > tlbs, I don't know the NPT format well enough yet to comment, but I > think when Avi just said we can't flush both tlbs in a single op > through tlb tagging like s390, will still require mmu notifiers. Still > if we can share the ptes it can save quite some memory for large VM, > so even if the mmu notifiers only have to deal with tlb flush + unpin > (without having to clear the NPT themself, anymore, because it was > already cleared by ptep_clear_flush) that may be still interesting to > consider. We have similar restrictions than you're naming here. Our guest may start at a (userspace-) page boundary, and has a fixed 1:1 mapping to userspace for a given length. We do that by just having one memory slot which has to start at virtual address zero in kvm. I have way to few knowledge about x86, but to me both the native page table layout and the nested one look very similar. I believe AMD has done a pretty good job designing that. > Which pdf were you reading? I believe it was http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
