From: Paolo Bonzini <pbonzini@redhat.com>
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Cc: gleb@redhat.com, kvm@vger.kernel.org,
xiaoguangrong@linux.vnet.ibm.com,
yoshikawa_takuya_b1@lab.ntt.co.jp
Subject: Re: [PATCH v2] KVM: MMU: Inform users of mmio generation wraparound
Date: Thu, 20 Jun 2013 23:29:22 +0200 [thread overview]
Message-ID: <51C37432.6000109@redhat.com> (raw)
In-Reply-To: <20130621013431.141491d8778b89a39d117bbc@gmail.com>
Il 20/06/2013 18:34, Takuya Yoshikawa ha scritto:
> From: Takuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp>
>
> 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 <yoshikawa_takuya_b1@lab.ntt.co.jp>
> ---
> 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)
>
next prev parent reply other threads:[~2013-06-20 21:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-20 16:34 [PATCH v2] KVM: MMU: Inform users of mmio generation wraparound Takuya Yoshikawa
2013-06-20 21:29 ` Paolo Bonzini [this message]
2013-06-21 0:48 ` Takuya Yoshikawa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51C37432.6000109@redhat.com \
--to=pbonzini@redhat.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=takuya.yoshikawa@gmail.com \
--cc=xiaoguangrong@linux.vnet.ibm.com \
--cc=yoshikawa_takuya_b1@lab.ntt.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.