From: Marcelo T. <mto...@re...> - 2008-04-24 17:11:24
|
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) |