| 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
| ||
|
Date: Sun, 29 Oct 2006 11:15:59 +0200 From: Avi Kivity <avi@...ranet.com> To: Anthony Liguori <aliguori@...ibm.com> CC: Arnd Bergmann <arnd@...db.de>, kvm-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org Subject: Re: [kvm-devel] [PATCH 6/13] KVM: memory slot management Anthony Liguori wrote: >> >> It's not about tlb entries. The shadow page tables collaples a GV -> >> HV -> HP double translation into a GV -> HP page table. When the >> Linux vm goes around evicting pages, it invalidates those mappings. >> >> There are two solutions possible: lock pages which participate in >> these translations (and their number can be large) or modify the >> Linux vm to consult a reverse mapping and remove the translations (in >> which case TLB entries need to be removed). >> > > If you locked pages that have active shadow mappings, you could then > use a secondary mechanism to invalidate existing mappings when necessary. > Yes. There are two needs: to propagate virtual machine activity to the host (by folding dirty and accessed bits from multiple shadow ptes into a single struct page), and to apply pressure from the vm to the guest (by invalidating all mappings of a given page). -- 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