From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH v2] KVM: MMU: Inform users of mmio generation wraparound Date: Thu, 20 Jun 2013 23:29:22 +0200 Message-ID: <51C37432.6000109@redhat.com> References: <20130621013431.141491d8778b89a39d117bbc@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: gleb@redhat.com, kvm@vger.kernel.org, xiaoguangrong@linux.vnet.ibm.com, yoshikawa_takuya_b1@lab.ntt.co.jp To: Takuya Yoshikawa Return-path: Received: from mail-ea0-f169.google.com ([209.85.215.169]:56891 "EHLO mail-ea0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422654Ab3FTV3b (ORCPT ); Thu, 20 Jun 2013 17:29:31 -0400 Received: by mail-ea0-f169.google.com with SMTP id h15so4330952eak.28 for ; Thu, 20 Jun 2013 14:29:30 -0700 (PDT) In-Reply-To: <20130621013431.141491d8778b89a39d117bbc@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: Il 20/06/2013 18:34, Takuya Yoshikawa ha scritto: > From: Takuya Yoshikawa > > Without this information, users will just see unexpected performance > problems and there is little chance we will get good reports from them: > note that mmio generation is increased even when we just start, or stop, > dirty logging for some memory slot, in which case users cannot expect > all shadow pages to be zapped. > > printk_ratelimited() is used for this taking into account the problems > that we can see the information many times when we start multiple VMs > and guests can trigger this by reading ROM in a loop for example. > > Signed-off-by: Takuya Yoshikawa > --- > Interestingly, I saw this information printed twice every time. > Looks like current_mmio_gen can become mmio_max_gen... > arch/x86/kvm/mmu.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c > index c60c5da..54e3968 100644 > --- a/arch/x86/kvm/mmu.c > +++ b/arch/x86/kvm/mmu.c > @@ -4385,8 +4385,10 @@ void kvm_mmu_invalidate_mmio_sptes(struct kvm *kvm) > * The max value is MMIO_MAX_GEN - 1 since it is not called > * when mark memslot invalid. > */ > - if (unlikely(kvm_current_mmio_generation(kvm) >= (MMIO_MAX_GEN - 1))) > + if (unlikely(kvm_current_mmio_generation(kvm) >= (MMIO_MAX_GEN - 1))) { There is an off-by-one here (that I can fix in a separate patch). The right test is >= MMIO_MAX_GEN, since we have: #define MMIO_MAX_GEN ((1 << MMIO_GEN_SHIFT) - 1) Paolo > + printk_ratelimited(KERN_INFO "kvm: zapping shadow pages for mmio generation wraparound\n"); > kvm_mmu_invalidate_zap_all_pages(kvm); > + } > } > > static int mmu_shrink(struct shrinker *shrink, struct shrink_control *sc) >