[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <459D21DD.5090506@qumranet.com>
Date: Thu, 04 Jan 2007 17:48:45 +0200
From: Avi Kivity <avi@...ranet.com>
To: kvm-devel <kvm-devel@...ts.sourceforge.net>
CC: linux-kernel <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...e.hu>
Subject: [PATCH 0/33] KVM: MMU: Cache shadow page tables
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.
--
error compiling committee.c: too many arguments to function
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists