Re: swapping with MMU Notifiers V2

[Carsten Otte <cotte-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>]

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/