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-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ