From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH] KVM: MMU: Inform users of mmio generation wraparound Date: Thu, 20 Jun 2013 15:46:46 +0300 Message-ID: <20130620124646.GL5832@redhat.com> References: <20130620175914.4e4f9eb3.yoshikawa_takuya_b1@lab.ntt.co.jp> <51C2E0AA.7060404@redhat.com> <20130620114504.GG5832@redhat.com> <51C2F718.1010500@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Takuya Yoshikawa , kvm@vger.kernel.org, xiaoguangrong@linux.vnet.ibm.com To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:32354 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757868Ab3FTMrU (ORCPT ); Thu, 20 Jun 2013 08:47:20 -0400 Content-Disposition: inline In-Reply-To: <51C2F718.1010500@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jun 20, 2013 at 02:35:36PM +0200, Paolo Bonzini wrote: > Il 20/06/2013 13:45, Gleb Natapov ha scritto: > > On Thu, Jun 20, 2013 at 12:59:54PM +0200, Paolo Bonzini wrote: > >> Il 20/06/2013 10:59, Takuya Yoshikawa ha scritto: > >>> 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 should never > >>> expect all shadow pages to be zapped. > >>> > >>> Signed-off-by: Takuya Yoshikawa > >>> --- > >>> 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..bc8302f 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))) { > >>> + printk(KERN_INFO "kvm: zapping shadow pages for mmio generation wraparound"); > >> > >> This should at least be rate-limited, because it is guest triggerable. > >> > > It will be hard for guest to triggers it 1 << 19 times too fast though. > > > >> But why isn't the kvm_mmu_invalidate_zap_all_pages tracepoint enough? > > > > This one will trigger during slot deletion/move too. > > > > I would put it in to see if it actually triggers in some real world > > workloads (skipping the firs wraparound since it is intentional), > > we can always drop it if it will turn out to create a lot of noise. > > Reading a ROM in a loop can trigger it in less than 5 minutes on my > machine. Not a lot of noise, but enough to be annoying. I think the > existing tracepoint is enough, or we can add a more specific one here. > 5 minutes after first wraparound? -- Gleb.