From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [PATCH 1/2] KVM: MMU: Mark sp mmio cached when creating mmio spte Date: Wed, 13 Mar 2013 15:42:18 +0800 Message-ID: <51402DDA.607@linux.vnet.ibm.com> References: <20130312174333.7f76148e.yoshikawa_takuya_b1@lab.ntt.co.jp> <20130312174440.5d5199ee.yoshikawa_takuya_b1@lab.ntt.co.jp> <5140094F.5080700@linux.vnet.ibm.com> <20130313162816.c62899dc.yoshikawa_takuya_b1@lab.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mtosatti@redhat.com, gleb@redhat.com, kvm@vger.kernel.org To: Takuya Yoshikawa Return-path: Received: from e28smtp03.in.ibm.com ([122.248.162.3]:44448 "EHLO e28smtp03.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754039Ab3CMHm2 (ORCPT ); Wed, 13 Mar 2013 03:42:28 -0400 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 13 Mar 2013 13:09:24 +0530 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id 12DDC394002D for ; Wed, 13 Mar 2013 13:12:22 +0530 (IST) Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2D7gI6Y31457282 for ; Wed, 13 Mar 2013 13:12:19 +0530 Received: from d28av02.in.ibm.com (loopback [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2D7gKEt000752 for ; Wed, 13 Mar 2013 18:42:21 +1100 In-Reply-To: <20130313162816.c62899dc.yoshikawa_takuya_b1@lab.ntt.co.jp> Sender: kvm-owner@vger.kernel.org List-ID: On 03/13/2013 03:28 PM, Takuya Yoshikawa wrote: > On Wed, 13 Mar 2013 13:06:23 +0800 > Xiao Guangrong wrote: > >> On 03/12/2013 04:44 PM, Takuya Yoshikawa wrote: >>> This will be used not to zap unrelated mmu pages when creating/moving >>> a memory slot later. >> >> How about save all mmio spte into a mmio-rmap? > > The problem is that other mmu code would need to care about the pointers > stored in the new rmap list: when mmu_shrink zaps shadow pages for example. It is not hard... all the codes have been wrapped by *zap_spte*. > > Maybe worth thinking about, but I want to have a simple, back-portable patch > for distributors, as a first step: note that creating a memory slot can happen > many times for some guest configurations since QEMU is doing strange things > for re-mapping some regions IIRC. Hmm, that means also need to delete memslot frequently, this patch can not help much on deletion case. > >> >> The good things are: >> - instead walking all shadow page, we can only walk the rmap > > Traversing the active list does not take such a long time compared to > other things to do for zapping pages: us, not ms order. But I'm now Walking shadow page depends on how much memory used on guest... > preparing for an additional work to avoid "goto restart" after deleting > entries. That will at least help us not to traverse more than once. If drop the walking, so you need not care "goto" stuff anymore... > >> - Comparing to zap a shadow page, it does not need to flush TLB after >> zapping mmio sptes > > If we check each spte in the sp, we can achieve the similar goal: > similar to the old remove_write_access() code. I implemented such > code but have not seen a clear improvement yet. Pros and cons will > be there. Checking every entries (512) in the shadow page is bad... > > Thanks, > Takuya > > >