On Wednesday 21 May 2008 21:47:40 Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > This code shouldn't be hit anyways, but when it is, it's useful to have a
> > little more information about the failure.
> >
> > Signed-off-by: Hollis Blanchard <hollisb@xxxxxxxxxx>
> >
> > diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
> > --- a/arch/powerpc/kvm/44x_tlb.c
> > +++ b/arch/powerpc/kvm/44x_tlb.c
> > @@ -145,7 +145,7 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcp
> > down_read(¤t->mm->mmap_sem);
> > new_page = gfn_to_page(vcpu->kvm, gfn);
> > if (is_error_page(new_page)) {
> > - printk(KERN_ERR "Couldn't get guest page!\n");
> > + printk(KERN_ERR "Couldn't get guest page for gfn %lx!\n", gfn);
> > kvm_release_page_clean(new_page);
> > up_read(¤t->mm->mmap_sem);
> > return;
> >
>
> FWIW, you should probably rate limit this sort of thing if this is what
> would get triggered if the guest tried to program the tlb with an
> invalid gfn.
That was my initial thought as well, but in general, kvmppc_mmu_map() is only
called if a TLB entry is "safe" -- meaning kvm_is_visible_gfn(kvm, gfn) was
true. So in the absence of bugs elsewhere, this should never happen... but we
know how that goes. ;)
Anyways, that's why I'm not worried about rate limiting here.
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
