From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Android-virt] [PATCH v5 08/13] ARM: KVM: Handle guest faults in KVM Date: Tue, 13 Dec 2011 15:23:37 +0200 Message-ID: <4EE751D9.4070907@redhat.com> References: <20111211102403.21693.6887.stgit@localhost> <20111211102509.21693.23709.stgit@localhost> <4EE61851.5070308@redhat.com> <4EE71EBF.2080700@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Marc.Zyngier@arm.com, android-virt@lists.cs.columbia.edu, tech@virtualopensystems.com To: Christoffer Dall Return-path: Received: from mx1.redhat.com ([209.132.183.28]:31352 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751129Ab1LMNXw (ORCPT ); Tue, 13 Dec 2011 08:23:52 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 12/13/2011 03:10 PM, Christoffer Dall wrote: > >> the question is just which mappings are the > >> most efficient to reclaim. > > > > Do you have accessed bits in those PTEs? > > > > nope. We can protect the underlying target pages though, but... Yeah, we have the same issue with one of the vendors. Fortunately only 90% of the market is affected. > > It's not really critical to have efficient reclaim here, since it > > happens so rarely. It just needs to do something. > > > > when would you trigger it - when it reaches a certain limit, or? And > then what, free the lot and re-allocate what's needed? The kernel triggers it based on internal pressure. It tells you how much pressure to apply, so you just translate it to a number of pages to free. > >> The other problem, the actual guest memory consuming too much memory, > >> I assumed this limit would be set by the user when creating his/her > >> VM, or can we do something smarter? (again, forgive my ignorance). > >> What is the alternative to pinning actual guest pages > > > > mmu notifiers - pages aren't pinned; instead, Linux calls back into kvm > > when modifying a host pte, and kvm responds by dropping or modifying its > > translation (second stage pte in your case). > > > > ah ok, so this works across VM boundary. Based on hyper-calls I presume? No, it's completely internal to the host. See for example kvm_mmu_notifier_invalidate_page() (in common code). It's called when Linux-as-host wants to change a pte (say to swap a page). kvm responds by translating the host virtual address into a guest physical address (via the memory slots table), then zapping the relevant pte and flushing and TLBs which may have cached the pte. > > mmu notifiers are also useful for other optimizations, like ksm, > > ballooning, and transparent huge pages. > > > > I know those features have to be supported eventually. The question is > if all this must be in place before a merge upstream? It doesn't have to be there for the merge but I recommend giving it high priority. At least read and understand the code so the addition will follow naturally. -- error compiling committee.c: too many arguments to function