From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM: MMU: nuke shadowed pgtable pages and pte's on memslot destruction Date: Sat, 05 Jul 2008 20:25:30 +0300 Message-ID: <486FAE8A.2050308@qumranet.com> References: <20080704010618.GA25834@dmt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Richard W.M. Jones" , kvm-devel To: Marcelo Tosatti Return-path: Received: from il.qumranet.com ([212.179.150.194]:12933 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752317AbYGERZN (ORCPT ); Sat, 5 Jul 2008 13:25:13 -0400 In-Reply-To: <20080704010618.GA25834@dmt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: Marcelo Tosatti wrote: > During RH6.2 graphical installation the following oops is triggered: > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 > IP: [] :kvm:gfn_to_rmap+0x3e/0x61 > Pid: 4559, comm: qemu-system-x86 Not tainted > RIP: 0010:[] [] :kvm:gfn_to_rmap+0x3e/0x61 > > @@ -1955,6 +1955,22 @@ void kvm_mmu_slot_remove_write_access(st > } > } > > +int kvm_mmu_slot_has_shadowed_page(struct kvm *kvm, int slot) > +{ > + struct kvm_mmu_page *sp; > + int ret = 0; > + > + spin_lock(&kvm->mmu_lock); > + list_for_each_entry(sp, &kvm->arch.active_mmu_pages, link) { > + if (test_bit(slot, &sp->slot_bitmap)) { > + ret = -EINVAL; > + break; > + } > + } > + spin_unlock(&kvm->mmu_lock); > + return ret; > +} > + > I don't like the guest influencing host actions in this way. It's just a guest. But I think it's unneeded. kvm_mmu_zap_page() will mark a root shadow page invalid and force all vcpus to reload it, so all that's needed is to keep the mmu spinlock held while removing the slot. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.