Re: WARNING: at /usr/src/modules/kvm/mmu.c:390 account_shadowed()

[Marcelo Tosatti <mtosatti@redhat.com>]

On Wed, Apr 23, 2008 at 09:30:06AM +0300, Avi Kivity wrote:
> > as I got no reply, I guess it is a bad setup on my part. If that might
> > help, this happenned while I was doing a "make -j" on webkit svn tree
> > (ie. heavy c++ compilation workload) .
> >
> >   
> 
> No this is not bad setup.  No amount of bad setup should give this warning.
> 
> You didn't get a reply because no one knows what to make of it, and 
> because it's much more fun to debate endianess or contemplete guests 
> with eighty thousand disks than to fix those impossible bugs.  If you 
> can give clear instructions on how to reproduce this, we will try it 
> out.  Please be sure to state OS name and versions for the guest as well 
> as the host.

It is valid to have more than PAGES_PER_HPAGE in the largepage's
shadowed count. If the gpte read races with a pte-update-from-guest (and
the pte update results in a different sp->role), it might account twice
for a single gfn.

Such "zombie" shadow pages should eventually be removed through
recycling, allowing for instantiation of a large page, unless references
can be leaked. Can't spot such leakage problem though.

Thoughts?

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2ad6f54..8ae2118 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -387,7 +387,6 @@ static void account_shadowed(struct kvm *kvm, gfn_t gfn)
 
 	write_count = slot_largepage_idx(gfn, gfn_to_memslot(kvm, gfn));
 	*write_count += 1;
-	WARN_ON(*write_count > KVM_PAGES_PER_HPAGE);
 }
 
 static void unaccount_shadowed(struct kvm *kvm, gfn_t gfn)

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone