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
_______________________________________________
kvm-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
