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 <[email protected]> > --- > 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. But why isn't the kvm_mmu_invalidate_zap_all_pages tracepoint enough? Paolo > kvm_mmu_invalidate_zap_all_pages(kvm); > + } > } > > static int mmu_shrink(struct shrinker *shrink, struct shrink_control *sc) > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
