linux-kernel - Re: [PATCH 0/33] KVM: MMU: Cache shadow page tables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 4 Jan 2007 09:22:26 -0800
From:	Andrew Morton <akpm@...l.org>
To:	Avi Kivity <avi@...ranet.com>
Cc:	kvm-devel <kvm-devel@...ts.sourceforge.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 0/33] KVM: MMU: Cache shadow page tables

On Thu, 04 Jan 2007 17:48:45 +0200
Avi Kivity <avi@...ranet.com> 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?
-
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/