Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935379Ab3DPCaa (ORCPT ); Mon, 15 Apr 2013 22:30:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40845 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935163Ab3DPCaW (ORCPT ); Mon, 15 Apr 2013 22:30:22 -0400 Date: Mon, 15 Apr 2013 21:54:39 -0300 From: Marcelo Tosatti To: Xiao Guangrong Cc: gleb@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v2 0/6] KVM: MMU: fast invalid all mmio sptes Message-ID: <20130416005439.GC1962@amt.cnet> References: <1364810209-25954-1-git-send-email-xiaoguangrong@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1364810209-25954-1-git-send-email-xiaoguangrong@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2894 Lines: 66 On Mon, Apr 01, 2013 at 05:56:43PM +0800, Xiao Guangrong wrote: > Changelog in v2: > - rename kvm_mmu_invalid_mmio_spte to kvm_mmu_invalid_mmio_sptes > - use kvm->memslots->generation as kvm global generation-number > - fix comment and codestyle > - init kvm generation close to mmio wrap-around value > - keep kvm_mmu_zap_mmio_sptes > > The current way is holding hot mmu-lock and walking all shadow pages, this > is not scale. This patchset tries to introduce a very simple and scale way > to fast invalid all mmio sptes - it need not walk any shadow pages and hold > any locks. > > The idea is simple: > KVM maintains a global mmio invalid generation-number which is stored in > kvm->memslots.generation and every mmio spte stores the current global > generation-number into his available bits when it is created > > When KVM need zap all mmio sptes, it just simply increase the global > generation-number. When guests do mmio access, KVM intercepts a MMIO #PF > then it walks the shadow page table and get the mmio spte. If the > generation-number on the spte does not equal the global generation-number, > it will go to the normal #PF handler to update the mmio spte > > Since 19 bits are used to store generation-number on mmio spte, we zap all > mmio sptes when the number is round Hi Xiao, Is it still necessary with generation numbers at 'struct shadow_page' level (which covers the slot deletion case). That is, once kvm_mmu_zap_all is fixed to increase generation count and nuke roots, can't that be used instead with similar effectiveness for SLOT_CREATE/SLOT_MOVE cases? > Xiao Guangrong (6): > KVM: MMU: retain more available bits on mmio spte > KVM: MMU: store generation-number into mmio spte > KVM: MMU: make return value of mmio page fault handler more readable > KVM: MMU: fast invalid all mmio sptes > KVM: MMU: add tracepoint for check_mmio_spte > KVM: MMU: init kvm generation close to mmio wrap-around value > > arch/x86/include/asm/kvm_host.h | 3 +- > arch/x86/kvm/mmu.c | 134 +++++++++++++++++++++++++++++++-------- > arch/x86/kvm/mmu.h | 17 +++++ > arch/x86/kvm/mmutrace.h | 34 +++++++++- > arch/x86/kvm/paging_tmpl.h | 10 ++- > arch/x86/kvm/vmx.c | 12 +++- > arch/x86/kvm/x86.c | 11 +++- > virt/kvm/kvm_main.c | 6 ++ > 8 files changed, 186 insertions(+), 41 deletions(-) > > -- > 1.7.7.6 > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/