Re: [PATCH 5 of 5] [kvm powerpc] Report bad GFNs

[Hollis Blanchard]

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 <[EMAIL PROTECTED]>
> >
> > 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(&current->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(&current->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" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html