Carsten Otte wrote: > Avi Kivity wrote: >> For one thing, kvm uses page->private to store its rmap information. >> This is lost if regular mappings are used. >> >> More importantly, both the regular address space and kvm will want to >> be called when a page is paged out, while this is doable, it isn't easy. > Taking the long way to call kvm on pageout seems to be preferable. On > 390 we don't need any callback when a page is swapped out. Actually > the pte is invalidated and next time the guest accesses that page we > receive a page fault which causes us to swap it back in. Would you > explain why that callback is needed on x86? >
The pte is stored/cached in two different places (in addition to what Linux already knows about): - in the shadow page tables - in the tlbs of the vcpus that may have referenced the page so, when swapping out the page, you need to use the kvm rmap to find all shadow ptes which reference the page, and also IPI every processor that is running a vcpu belonging to the same virtual machine. You also need to extend kvm rmap to contain read-only pages (as this patchset does). That's a cost that may have a serious performance impact. s390 uses the same pte for userspace virtual and guest physical? that explains why a single invalidate suffices for both. But aren't guest virtual translations cached in the tlb as well? An example: suppose host pfn 7 is allocated as guest pfn 8 (and therefore, userspace address 0x8000). Suppose further the guest maps guest pfn 8 to guest virtual 0x10000 and guest virtal 0x11000. Aren't there three tlbs you need to shoot down? host virtual 0x8000->pfn 7 and guest virual 0x10000->pfn 7 and 0x11000->pfn 7? (Assuming page size is 4k) -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
