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 20:42:41 +0800 Message-ID: <51407441.4020200@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> <51402DDA.607@linux.vnet.ibm.com> <20130313123358.GM11223@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Takuya Yoshikawa , mtosatti@redhat.com, kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from e23smtp09.au.ibm.com ([202.81.31.142]:55797 "EHLO e23smtp09.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755167Ab3CMMm4 (ORCPT ); Wed, 13 Mar 2013 08:42:56 -0400 Received: from /spool/local by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 13 Mar 2013 22:35:03 +1000 Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [9.190.234.120]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id 3C1E6357804A for ; Wed, 13 Mar 2013 23:42:44 +1100 (EST) Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2DCTxoH34996454 for ; Wed, 13 Mar 2013 23:29:59 +1100 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2DCghP3018358 for ; Wed, 13 Mar 2013 23:42:43 +1100 In-Reply-To: <20130313123358.GM11223@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 03/13/2013 08:33 PM, Gleb Natapov wrote: > On Wed, Mar 13, 2013 at 03:42:18PM +0800, Xiao Guangrong wrote: >> 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*. >> > So are you going to send a patch? What do you think about applying this > as temporary solution? Hi Gleb, Since it only needs small change based on this patch, I think we can directly apply the rmap-based way. Takuya, could you please do this? ;)