From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH 0/33] KVM: MMU: Cache shadow page tables Date: Thu, 4 Jan 2007 09:22:26 -0800 Message-ID: <20070104092226.91fa2dfe.akpm@osdl.org> References: <459D21DD.5090506@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , linux-kernel Return-path: To: Avi Kivity In-Reply-To: <459D21DD.5090506-atKUWr5tajBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Thu, 04 Jan 2007 17:48:45 +0200 Avi Kivity wrote: > The current kvm shadow page table implementation does not cache shadow > page tables (except for global translations, used for kernel addresses) > across context switches. This means that after a context switch, every > memory access will trap into the host. After a while, the shadow page > tables will be rebuild, and the guest can proceed at native speed until > the next context switch. > > The natural solution, then, is to cache shadow page tables across > context switches. Unfortunately, this introduces a bucketload of problems: > > - the guest does not notify the processor (and hence kvm) that it > modifies a page table entry if it has reason to believe that the > modification will be followed by a tlb flush. It becomes necessary to > write-protect guest page tables so that we can use the page fault when > the access occurs as a notification. > - write protecting the guest page tables means we need to keep track of > which ptes map those guest page table. We need to add reverse mapping > for all mapped writable guest pages. > - when the guest does access the write-protected page, we need to allow > it to perform the write in some way. We do that either by emulating the > write, or removing all shadow page tables for that page and allowing the > write to proceed, depending on circumstances. > > This patchset implements the ideas above. While a lot of tuning remains > to be done (for example, a sane page replacement algorithm), a guest > running with this patchset applied is much faster and more responsive > than with 2.6.20-rc3. Some preliminary benchmarks are available in > http://article.gmane.org/gmane.comp.emulators.kvm.devel/661. > > The patchset is bisectable compile-wise. Is this intended for 2.6.20, or would you prefer that we release what we have now and hold this off for 2.6.21? ------------------------------------------------------------------------- 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