I am currently working on supporting nested paging for KVM. As of now, I am able to boot 32-bit Linux guest (ttylinux) under AMD-V nested paging. My plan is to support a full-fledged of Linux guests and Windows guests in the next few weeks.
The current KVM MMU code was not designed with hardware assisted paging (i.e. nested paging or extended paging) in mind. For instance, some functions in kvm_main.c (i.e., write_cr functions) need to become become function pointers. Guest page table walking also needs some re-work. It will be nice to have both SMP and hardware assisted paging (NPT and EPT) in place for the next phase of KVM MMU code. I will be happy to provide help and work on these these areas. :P Best, -Wei Operating System Research Center Advanced Micro Devices (AMD) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Avi Kivity Sent: Thursday, March 15, 2007 3:43 AM To: Nakajima, Jun Cc: [email protected] Subject: Re: [kvm-devel] Status of SMP? Nakajima, Jun wrote: > The key is the virtual MMU; getting bootstrap/IPI working is > straightforward. I'm glad to hear you say that. > Without NPT or EPT, we need to have an SMP-capable shadow pagetable > code. I think one of the most efficient ways is to re-use the code > from Xen. The current one is the third generation of the shadow page > table, and it works well. > I'm fairly certain a rip-it-the-old-and-plug-in-the-new approach would be rejected. Linux development requires incremental patches. I'm not familiar with the current Xen shadow code, but a cursory look gave the following impressions: - it is single threaded, so there's no reason to expect more scalability out of it - it is lighter weight, by not maintaining a full reverse mapping. on the other hand, it is less generic (requires special handling for linearized page tables) - does order 2 allocations (which work in Linux, but get less reliable as uptime increases) I don't see a compelling reason to change here, but of course I may have missed something and I'm also biased. Getting the kvm mmu to do smp involves the following, as far as I can tell: - verifying that all the locking in place is correct - make sure that spurious faults (due to races) are handled well - install shadow ptes atomically instead of building them incrementally - replace local tlb flushes by remote tlb flushes (for cpus that have touched the domain, and later, for cpus that have touched the pagetable) -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE V _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
